No, not that Enterprise.

Nope. Try again.

This is about “the enterprise,” the notion of organizations that upgrade software less often than once every six weeks, and one vendor that wants to push things along, no matter the cost to the users…

WordPress powers tens of millions of Web sites (including this one). They estimate roughly one in four of all Web sites, in fact. Because of how prevalent they are, the folks behind WordPress are very cautious in when and how they make changes to their software. WordPress only requires PHP 5.2 (a version that hasn’t actually been supported since 2011). PHP itself is up to version 7.1.

WordPress runs just fine on PHP 7.1, by most accounts. And in fact PHP 7.1 runs a lot faster, and supports a lot of fancy new features. Why wouldn’t you want to update?

Faster! New stuff! This sounds great!

But. (You knew it was coming.)

Actually, instead of a traditional “but,” let’s talk about Yoast.

Yoast (so named, I believe, because that’s the proper pronunciation of founder Joost de Valk’s first name) makes plugins for WordPress, including a very popular plugin for “search engine optimization.” That’s the mysterious art of getting your content to come up first on Google. Their developers would like to use some of the nifty new features in those newer versions of PHP, and they’ve decided to mount a bully pulpit of sorts. They’ve written a long, and relatively thorough, post explaining what they want to do, and why. And in principle, it sounds good.

There are a couple flaws in their logic, however.

First: Just because something isn’t supported, doesn’t mean it isn’t supported.

At my work, we use Red Hat Enterprise Linux. Red Hat‘s business model is based on making software with a nice, long, stable lifecycle. While the original developers of PHP have long since given up on PHP 5.3 (an older version, last supported by them in August 2014), Red Hat hasn’t. Whenever bug fixes or security issues are discovered with newer versions of PHP, Red Hat determines if those issues are relevant for the older versions they support, and “back-port” the relevant fixes. This means that even though the original creators of PHP haven’t supported PHP 5.3 in a few years, Red Hat will continue to support it through November 2020 (at least).

Yoast contends (and they are technically correct, in some sense) that these older versions of PHP are actively hazardous, and want to get rid of them. Thus, at some point in the next few weeks, Yoast plans to add a lovely message to the top of every back-end and admin page on a WordPress site that’s running an “unsupported” (in their view) version of PHP:

They’re not just showing it to site admins, as I understand it. They’re showing it to everyone, including lots of users that won’t actually be able to do a darn thing about it.

Their current plans will have them slowly inching up the chain of “versions of PHP they don’t like,” ultimately covering over half of all Web sites running WordPress and the Yoast SEO plug-in.

In my network, this message will be seen by a half-dozen developers, a few managers, and many hundreds of end-users that don’t even know what a PHP is, much less how to update it. And the only people who could update it are a few sysadmins, who rarely actually visit any of the sites.

Which leads to my second point:

End-users are not acceptable collateral damage.

At least in my use-case, very nearly 100% of the people who log into our WordPress sites won’t be able to do anything about this message, and very nearly 100% of those won’t even understand it. In the very best case, that large message (that can’t be removed unless/until you upgrade your PHP) will take up half a screen at the top of everything you do in the WordPress back-end. At worst, it will irritate, confuse, antagonize, and anger the end-users.

While WordPress itself seems to run just fine under the newest versions of PHP, that doesn’t account for the thousands of plug-ins and themes, little bits of custom code, and nasty hacks that the boss’ kid cooked up after taking that one programming class. There’s no practical way to ensure, on a wide basis, that these upgrades are actually safe. It may actually be impossible. This is probably why WordPress hasn’t yet chosen to force users to upgrade. It’s a bit backwards, especially for the WordPress developers who don’t get to use all the new gizmos and features of the current version of PHP, but they graciously bear this burden because it’s in the best interest of the users.

Professional Web hosting companies will generally make sure this is a non-event for their customers. My organization isn’t a professional Web hosting company, though. We have a few developers and sysadmins, but our foremost goal is to ensure our sites stay up. There’s no requirement that they be running bleeding-edge technology for that to be the case. Heck, in many cases bleeding-edge and stability are completely cross-purposes.

(My employer has been around for over 150 years. Anecdotally, it seems like older organizations are more likely to favor long-term stability, and younger organizations are more likely to be faster and more agile.)

All this comes round to my last point, borrowed from one of those other Enterprises above:

The needs of the many must outweigh the needs of the few.

I’ve got 400+ Web sites to maintain. Things are working very well as-is. We’re on a platform that’s supported for several years yet, except for one plugin developed by one small company that’s itching to use features that many of the rest of us are able to avoid, and by and large the rest of us are doing just fine.

Yes, we are a bit behind the times in some sense. Heck, our developers would love to update things, but the benefits of a stable, supportable enterprise-friendly platform outweigh the benefits of upgrading one piece of software to appease one vendor.

Sorry, Yoast (and Joost), but there’s a very good chance I’ll be bulk-uninstalling your SEO plugin in the near future.