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 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.

Almost everyone who reads us knows Matt Mullenweg, the leader of Automattic/Jetpack, and the WordPress project. And you may know David Heinemeier Hansson (DHH) from his leadership of the Ruby on Rails project, or from their app Basecamp.

And this podcast episode, from Basecamp’s Rework podcast, where Matt and DHH discuss control and power of open source. The discussion was catalyzed by Automattic’s recently announced round of funding from Salesforce.

I’m not sure there’s a single revelation in the podcast, if I’m honest. But it’s very interesting to hear two people whose work and values I respect a great deal (for different reasons) discuss anything together. Especially something as consequential as the consolidation of power under capitalism, what a Chrome (browser) based mono-culture mean to the open web, and what role they should plan in all of that. Give it a listen!

Found from Ben in the MasterWP newsletter, I love this hilariously short bit of advice about how to be a better programmer. In it, Pete Shirley, who calls himself “a poor programmer” says it’s helped him as someone who thinking they’re in the bottom quartile of all programmers. I kind of doubt he really is, because the advice is way better that what a lot of “elite” programmers tell you about. And it’s very approachable.

Here’s his preamble

I am a poor programmer.  Ask anyone who has worked on group projects with me.

But the key compensation is I am aware I am a poor programmer.  I do not try to do anything fancy.  I follow some heuristics that keep me productive IMO.  I think these heuristics are in fact good for all programmers, but are essential for those of us in the bottom quartile.

Because I don’t want to spoil the whole list, I’ll just tell you that it’s 8 things and that it’ll take you under a minute to read.

Back in 2007, when I was just coming to terms with WordPress, Justin Tadlock was out at the forefront of what I understood WordPress to be. In the (gosh!) 12 years since, Justin’s stayed busy in the WordPress space, but also done some other things like share on his blog about his small farm.

On the whole, Justin is in my mind one of those people that belongs on a Rushmore of WordPress. He’s just always loomed large, has taught me a lot of what I know, and has always seemed humble and generous while doing it.

All of this is just to explain why I thought it interested and notable enough to share the fact that Justin has stepped into the shoes left behind by Jeff Chandler at WP Tavern. If you don’t follow it, the Tavern has been a prominent voice in WordPress for a long time. It has been bankrolled by Matt Mullenweg for the last (memory fails me, I looked it up) 6 years, and I’m really excited to see what comes next form Sarah Gooding and Justin over there.

Digital Ocean, a popular VPS hosting provider, recently announced a hosted-MySQL platform. The reasons you may want to do use this (vs putting the MySQL instance on the same server as your WordPress wed server) are a little more subtle than I want to get into here, but suffice it to say you’d get better scalability but a possibly more complex setup. For that reason, I’m linking to this tutorial on the topic from Mark Drake.

I’ve got an interest in using this for some syncing of my various development environments. But enough about me.

This tutorial does a few great things, but the most interesting one is that setting up of the database. In many ways, the rest is a fairly common WordPress install guide. The use of Apache (vs Nginx) is one of the aspects of that stuff we could have long debates about, but again I’ll defer that discussion to other venues and opportunities.