WordSesh was the first (at least to my knowledge) WordPress-focused virtual conference. The last one ran in 2016, and since than I’ve from time-to-time heard pining for its return. Brian Richards from WPSessions is doing just that: bringing it back.

A few things have changed, most notably that the schedule is 12-hours, and admission is no longer free. But the price is modest ($25 US) and 12 hours feels much more realistic to me than 24. I also know that Brian is paying speakers and making sure that all the talks are transcribed. These are two very cool changes, and things that have pushed him to charge for admission.

I’m most excited by the speaker and talk lineup. Brian is someone whose taste about dev-conferences I have a high degree of trust in. I’m also really happy that Brian clearly made an effort to have a diverse line-up. He’s pulled in not just a diverse-looking group of speakers, but a diverse set of topics as well.

If you’re free on Wednesday, July 25th, I encourage you to watch live. If you can’t watch live, I think it’s a great conference to watch replays of after the fact. No matter what, you should definitely give the site a quick perusal.

We’ve made a Facebook group. We’re not completely sure how it’ll work, and what’s allowed, but we’re really interested in seeing what more we can do with more frequent communication in a space that a whole bunch of people are already hanging out. So check it out and play along with us.

We’re trying our best here are WPShout to make sure that you’re learning everything we can usefully teach you about WordPress. We’re continually trying new things, and seeing if it helps. We’ve been selling Up and Running for years, and we know it’s really helping people. We’ve been selling WordPress Security with Confidence, and that’s been good (though less clearly what the market needs or wants). People love that we’re maintaining and improving WPHierarchy.com, and I’m hopeful that WPSecurityCompared.com can become similarly useful and loved. We’re looking at putting together a “PHP for WordPress Course” and a paid, supportive learning community–far more ambitious than a Facebook group :).

Anyway, that’s all just to say that we’re trying things. We hope we can make a group that’s free, useful to us, useful to you, and that everyone is happy exists. We know that that requires some less-fun things like moderation of members and comments, steering the community, etc. We’re hoping that the less-fun pales in comparison to the value it provides on both side. And so we’ve got a Facebook Group.

Over on Thoughtful Code, I spilled a bunch of words about semantic version numbers. WordPress 4.9.6 is imminent, and it got me to thinking about why semantic version numbers are so important to me. And because WordPress matters a lot to me, I think a lot about the (weird) way WordPress does version numbers.

On the topic of 4.9.6 in particular, here’s what I say:

So why, in May of 2018, is WordPress releasing 4.9.6 as a “major” version? Because, for political reasons, BDFL Matt Mullenweg is holding WordPress 5.0 to be the release where the new visual editor “Gutenberg” is added. This means that if the WordPress team want to release something before 5.0, they must release a 4.x. And because in WordPress we’ve never seen version numbers like 4.10.0, we’re stuck with a major set of new features coming out in 4.9.6.

I think it’s great that WordPress is getting GDPR-compliance-based changes. I think it’s great that Gutenberg isn’t stopping all forward-progress on the rest of WordPress. But I really don’t like that 4.9.6 isn’t as safe and simple a release as 4.9.1 or 4.9.5. No one will know that from version number alone either.

I’m really excited about the future of WordPress, with Gutenberg on the horizon. But WordPress’s steadfast refusal to acknowledge that semantic versioning is a useful and worth practice continues to grind my gears. Now that it’s undeniable the Gutenberg hasn’t made the (artificial, silly) April deadline, we’re officially in the time of silly and counter-productive holding pattern because of a feature that’s delaying a release. It’s not the end of the world, but it sure is silly.

I get like four emails a day about the GDPR, and because we’re not Facebook, Google, or an ad network, it doesn’t seem world-shaking to what we do. But I wanted to know a bit more, and so I Googled for “ELI5 GDPR,” “ELI5” being short for “Explain Like I’m Five,” Reddit’s awesome format for simplifying complex topics.

This Medium article is a decent high-level introduction to the topic. I came away feeling that the GDPR is basically a Good Thing that will stop big companies from doing sketchy stuff with consumer data—at least to EU citizens :(.

That left me still wanting an ELI5 for is “How do I know if this matters to my particular business, and if so what parts it matters to?” So I searched a bit more and found the linked article. It contains a good list of user rights that the GDPR encodes, and some more practical stuff about opt-ins.

From my best reading, the only way I think GDPR will really affect our particular business is making sure we don’t auto-subscribe anybody to our mailing list, which we already don’t. I’m guessing that most non-enormous websites (as opposed to web applications like Airbnb or Twitter) will be in a similar boat.

If you do business in the EU, worth at least a skim to know what kinds of things are and aren’t under discussion.

I thought Nashville was so fun for WordCamp US last year that I just had to get back before December. ;p

Ok, that’s not specifically true, but I did enjoy the city and am excited to be speaking at Southeast PHP there in August. I’ll be giving a talk I’ve given a few times before, which I really love and think is great. If you can’t make it to Southeast PHP, you can buy a recording of the talk at Nomad PHP, or read the article that inspired the talk right here on WPShout.

I’ll be there in Nashville in August repping Thoughtful Code at this inaugural PHP conference. I’m really excited to see that the organizers put together a great mix of speakers in the lineup, and learn a whole bunch more about the (arguably second, though I still think first) most important language to WordPress today. Come along!

Short answer: Yes!

I mean, “developer” means a lot of things. A competent WordPress developer can be a massive help to your business, but it’s relatively rare that the bulk of that person’s work is hardcore “software engineering,” as in “we built the Google search algorithm and then Google Maps.” It makes sense that that kind of work be better compensated on average.

Then there’s the issue that many or most WordPress “developers” are actually somewhere on the scale of “implementer”: they can install themes and plugins and work with their settings, but can’t fully engage with WordPress as a software project at the level of code. This tends to dilute the WordPress developer marketplace as specialists are competing with non-specialists for the same work. Obviously, individual skillsets vary in any software project—but this simply isn’t as much as an issue in the world of, say, Node.js developers.

Relatedly, many or most WordPress projects are for individuals or for small businesses. Other softwares are almost uniformly for startups, enterprise, government, and other large and large-budget entities.

So these are all great reasons why WordPress developers are, on average, less expensive than developers in other software ecosystems. The linked article is great because it takes an empirical look at the question—and, on the way, gives some great information that will help you understand how the people in your industry set prices.

In the wake of the VW diesel-emissions testing scam and the effect of various Facebook impacts on the 2016 US Presidential election, I’ve seen a marked shift toward people I respect as “thought leaders” (though I hate that phrase) thinking and talking more about the ethics of the code we as developers write.

Morten is certainly a thought-leader, and this remarkably long-and-complete essay for Smashing Magazine about applying the philosophy of ethics to web design is well worth a read for someone interested in either field.

The highlight for me was the conclusion:

In the end, ethics is a practice we all need to work on every day. To borrow a quote from Robert M. Pirsig:

“The place to improve the world is first in one’s own heart and head and hands, and then work outward from there.”

I struggle to keep up an interest in academic philosophy of the type that Morten so ably covers. But I do know that I can and do regularly see the direct results of what I do in the world and the people I know in it. And that, more than any abstraction, is the basis from which I try to check all choices I make. After all, as I wrote over on Thoughtful Code, I believe pretty firmly that programming is about people.

I installed Simple Lightbox on WPShout a few weeks ago, and it’s something I wish I’d done long before.

This free plugin takes WordPress’s default behavior with image links from “navigate to a new URL with just the image” to “open the image on the current page in a pop-up lightbox.” If that language isn’t clear, click the image below to see an example of Simple Lightbox in action:

Lightboxes are an obviously better user experience than clunky navigation and back-navigation, but I’d always hesitated to put something like Simple Lightbox onto WPShout because I didn’t know how it’d interact with our CDN, our lazy loading plugin, and so on. As it turns out, I needn’t have worried. I did run into a compatibility issue on another site (not Simple Lightbox’s fault, I believe), and on that site was able to use the similar and also high-quality Responsive Lightbox by dFactory.

The only concern I’ve got with Simple Lightbox so far is that it doesn’t let you specify which image size displays in the lightbox—it’s always the full-sized image. So if you upload a 15MB 10000px-by-8000px image, that’s what the lightbox will show, even on someone’s mobile phone. I’d love to see them make that an user option. Overall, though, highly recommended!

As Gutenberg gets closer, more and more people are trying to wrap their head around it. Zac Gordon’s Gutenberg development course is perfect if you’re really getting into it. But if you’re just looking into how to get started, this blog post he made a few months ago is as relevant and accurate as ever.

I love how succinctly he starts as well:

“How do I enqueue my block JavaScript and CSS to work with the Gutenberg Editor?”

The short answer is there are two ways:

• enqueue_block_editor_assets – For enqueueing JavaScript and CSS in the admin editor only.
• enqueue_block_assets – Enqueues on both the frontend of the site and in the admin editor (unless !is_admin() is used then it just enqueues on the frontend only).

If you come to the post with that exact question, this “TL;DR” may be enough for  you. And if you need more detail, he goes into it. It make for a much more handy quick reference than many articles. Including *cough* my own *cough*. Something I should consider doing… ?

The WordPress Marketing team has put together a pretty cool resource: a guide to a lot of the weird lingo you’ll hear casually cast-off in WordPress conversations without context. While I hope that this can move to a more canonical place: jargon.wordpress.org (with a built-in quick-search feature) would be AMAZING, I love the approach that Bridget Willard and the team have taken to break down some of the unintended barriers that new people to WordPress face.

I think a lot about the selective blindness that people (like myself) inside the community have toward things like jargon. I make a conscious effort to never mention a bit of jargon more than two times in a conversation with people whose experience level I don’t know without defining the terms. But I also know I fail at that sometimes, and even that’s an imperfect way to bring people up-to-speed.

It’s important to think hard about what the experience of new people to WordPress (or any technology) is. Too often that’s a thing that no one thinks about, and great tools die as a result of the poor user experience. I see Gutenberg as a step in the right direction there, and I think this is too.

If you’re in and around Colorado, or you just want an excuse to visit, you should come out to WordCamp Denver this year. Rather than just being a supporter, I’m on the organizing team this year.

We’ve just opened our Call for Speakers (CFP, in common industry lingo). You can and should apply. We’re hoping to make it a great one and I think you’d love to give a talk here. A couple big dates to know:

• May 4 is when the CFP closes
• May 31 is the latest you should know whether you’re accepted
• July 28 & 29 (Saturday and Sunday) at the days of the normal conference and half-day workshops respectively

The conference will be at the University of Denver again this year, and you should totally come (even if you don’t talk)!