I really appreciated this list from Callie West of conferences for 2020 that may be of interest to WordPress developers. While I trust that her list isn’t exhaustive, it does cover all the big conferences that were on my mind for the year, and a few I’d never heard of. Which means her list is doing its job absolutely perfectly.

In summary you should check out this list if you’re interested in seeing the major conferences in these buckets:

• WordCamps
• JavaScript conferences
• Laravel and PHP conferences
• CSS confs
• UX, development in general, and more

If any of those interested you, please give the article some love. She also finishes with some advice for those of you who might have to convince a boss to help you pay for a conference trip 🙂

Among the most difficult challenges in WordPress development is finding out where a piece of code actually lives. Up to two themes and infinite plugins could be hooking into any part of WordPress and changing things, and if you want to track down a specific change it’s often the most time-consuming part of an otherwise easy job.

This week, I found out about a cool plugin that lets you do a string search of anything on your WordPress filesystem—one theme, one plugin, all themes, all plugins, the entirety of wp-content, and more. I tried it out and it works as advertised. It’s the WordPress filesystem equivalent to the visibility a plugin like Better Search Replace helps provide into the WordPress database.

I wouldn’t rely on either plugin as infallible (I’m not sure if Better Search Replace can find serialized data, for example), but they’re a much better place to start than poking aimlessly around themes and plugins and trying to read a previous developer’s mind.

I really enjoyed reviewing this post from Steve Burge over at PublishPress (whose plugin we recently published a Quick Guide about). What he covers is the dream of Google Docs-style collaboration in WordPress’s native post editor. As he highlights, this is something that Matt Mullenweg has kind of committed the WordPress project to, and a great feature for us all if/when it arrives.

But what I really value about Steve’s post is that he’s honest and clear about the likely timeline and reviews some of the complications and related projects. As an example, he doesn’t think this is likely to be done very quick…

In terms of timeframe, I don’t expect Phase 2 of Gutenberg (“Customization”) to be complete before the end of 2020.

So that means that Phase 3 of Gutenberg (“Collaboration”) won’t be the main focus until 2021. Given that schedule, and the steep technical challenges, it’s almost certain that collaborative editing will not arrive in WordPress until 2021 at the earliest.

While it may sound pessimistic, I share Steve’s vision of the most likely timeline. The feature will surely be worth the wait, but it’s probably best if we expect a wait. 🤓

As far as I know, I’ve never gotten editing a hosts file to work. That’s a bummer, because sometimes you need to preview a site you’ve just migrated to new hosting, without pointing the DNS over and dealing with the horrors (wonders?) of DNS propagation. hosts is supposed to make that easy, but—at least in my experience as a Windows peasant—it’s super-hard to work with and doesn’t perform as advertised.

I just migrated a site to Kinsta (more on that later!), and in their detailed documentation on site previewing, they mentioned a service I’ve never heard of before: skipdns.link, a service with what I find to be an extremely hard-to-remember name that is also extremely useful.

It basically circumvents the need for a hosts file: you enter the new IP address where your migrated site lives, and the domain name it will eventually live at, and SkipDNS lets you browse the site completely naturally at a temporary domain name it generates.

It’s slightly hard to describe without trying it, so check out the service. I was blown away, and I think you will be too.

I was recently talking to my friend Jeremy and mentioned that I’d never quite made a “production” Gutenberg block, but had been meaning to learn for as long as that’s been a thing. (For shame!)

He pointed me to his (for lack of a better term) meta-tutorial about learning to write code for Gutenberg block. I really appreciated it. Especially because he talks specific about his process of making sense of all the concepts involved and highlighting which resources he found the most useful in doing that.

If that sounds at least a little interesting to you, give it a look. It’s where I’m going to start when I finally (probably because of an upcoming client project) have to fully and completely come to terms with the state of modern Gutenberg block development.

I’ve never really been someone who contributed to WordPress in a disciplined and direct way. (Which is to say, I’ve never had code I’ve written pulled into the WordPress project.) As a result, I can’t really say what the cognitive landscape of doing that is like. Which is precisely why I found this article from Alain Schlesser (best known to me for his work on WP-CLI) so interesting.

Here’s the crux what he’s writing about:

It’s a community full of passionate and inspiring people, and when you come into contact with it for the first time, it can be very intoxicating – I was hooked right away!

But with time, I noticed more and more that this highly inspiring and addicting environment did have a negative long-term effect on some community members.

I witnessed stress, anxiety, and burn-outs amongst the contributors, and a lot of churn in general. So I wondered why such a seemingly positive environment and noble common cause could have such a bad outcome for some people.

I believe that all of this can be traced back to a very simple root cause: Cost.

That is a short and inadequate summary of his good piece. I also found Heather Burns’s comment insightful (though I’m holding back from endorsing it).

I have a great deal of interest in and respect for Ben Thompson, the proprietor of Statechery, one of the most interesting “tech industry analyst” publications I’ve come across. So this interview he did with John O’Nolan, the founder of Ghost, was quite interesting.

For those who don’t know here’s my brief (and likely inaccurate) summary of John and Ghost. John O’Nolan started Ghost with the intent of making a better UI for the core “WordPress blog” experience. A series of decisions later, and Ghost is an open-source Node (JavaScript) server (not PHP, like WordPress) which is beautiful and modern, and either self-hosted or hosted at Ghost(Pro) (very similar to WordPress.com hosting).

One of the most interesting parts of their conversation, to me, is below (Ben, questioner, is in bold. John, answering, is non-bolded.):

What we’re launching now [in late October 2019] is native membership and subscription functionality directly inside the platform itself, so you can have people sign up to your site, log into it, and then you can connect your Stripe account and take recurring monthly or yearly revenue from them.

So to be super clear: this is a Ghost-the-open-source-project offering, not a Ghost-the-managed-hosting-company offering — is that right?

JO: That’s exactly right. Every single piece of it is completely open source and available under the MIT license.

So basically anyone can go and download Ghost like they could before today, they can run it on their own server like they could before today, and they can manage their own subscription business without having to pay you a dime.

JO: That’s exactly right.

How do you make money doing this?

JO: We already have an existing business model that works very well for us and we really aren’t looking to change that too much. The current business is doing very well, and we feel that if we can attract more people to using Ghost full-stop then that existing business model will continue to work for us. Anyone can self-host if they wish, but if they choose to pay us, then our costs only go up if we get more customers, so there is alignment there.

I can see both why this posture makes sense for Ghost, and why it’s not exactly the thing we’d want baked-in to WordPress. But it sure is interesting to think about how different this model is than the roiling WordPress ecosystem (in which I’m guessing there are at least three (paid) plugins for doing some variant of what this new feature of Ghost does, one of which might feel polished). 🤓

That said, don’t stop reading the interview there. Ben asks great questions (and John gives thoughtful answers) to the hit-by-a-bus problem, why they aren’t getting rich, and a whole lot more.

WordPress just released today (Tuesday, Nov 12). If, like me, this release kind of snuck up on you, the first place to stop should be this WordPress 5.3 Field Guide. What it does very well is touch on all the more out-of-the-way features of the release with easy-to-access links so you can dig deeper into any particular topic where you feel particularly intrigued (or worried about some old code you wrote, etc).

Hopefully, WordPress 5.3 is a rather uneventful release. As Matt’s State of the Word this year highlighted in way I’d entirely forgot, it was almost a year ago that all the hub-bub and tumult of Gutenberg in Core was upon us. I’m feeling great that WordPress 5.3 is not that momentous, and I’m hearing no complaints about how it’s about to crater anyone’s productivity. So we can just go back to what we were doing before: building the web with WordPress.

And that’s what makes a really great release.

I didn’t attend WordCamp US this year, for the first time since it started. As such, I was eager and excited to watch the State of the Word, which is definitely the most attention-getting talk of the conference to me. Thankfully, it did get published quite quickly. It’s already on YouTube:

Even before I watched it, I will also highlight that I was looking into the Post Status summary over the busy weekend. Definitely worth keep it on your radar, even if this year felt a little less “newsbreaking” to me than prior years.

I was pleasantly surprised to learn about this WordPress 5.3 feature which in highlighted by Justin Ahinon on Make WordPress Core. The issue it’s meant to solve is an uncompressed 12 megapixel fresh-from-the-phone type of photo being comically too large for your WordPress site.

In my playing with the WordPress media APIs I’ve never loved, but none of this looks like it’d cause obvious probelms:

When a new image is uploaded, WordPress will detect if it is a “big” image by checking if its height or its width is above a big_image threshold. The default threshold value is 2560px, filterable with the new big_image_size_threshold filter.

If an image height or width is above this threshold, it will be scaled down, with the threshold being used as max-height and max-width value. The scaled-down image will be used as the largest available size.

In this case, the original image file is stored in the uploads directory and its name is stored in another array key in the image meta array: original_image. To be able to always get the path to an originally uploaded image a new function wp_get_original_image_path() was introduced.

Now that WordPress is actively pushing the community and sites that run it toward more modern versions of PHP, it’s extra important to follow language changes. That’s where this summary of the most consequential features of the forthcoming PHP 7.4 for WordPress development form Jonathan Desrosiers comes in. He does a great job of quickly and approachably explaining all the features and changes that the language will bring.

I was happy to learn that none of the changes really affect code I typically write, but this change was the most striking to me. Mostly because it highlighted a weird ambiguity in the PHP API I wasn’t aware of:

Specific Parameter Order Requirements For implode()

The implode() function accepts two parameters, $glue and $pieces. For historical reasons, implode() has accepted these parameters in any order, though it has been a recommendation that the documented order of implode( $glue, $pieces ) be used.

Starting in PHP 7.4, tolerance for passing the parameters in reverse order is deprecated and will be completely removed in PHP 8.0. Calling implode( $pieces, $glue ) in PHP 7.4 will trigger a deprecated notice.