Proposal: Dropping support for old PHP versions via a fixed schedule

While most people here will probably mostly know me as a (PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher) developer, I actually have a background in business studies, so when Matt Mullenweg reached out to me to continue the conversation about WordPress dropping support for older PHP versions in an in-person call, I decided to put my business acumen to use and see if I could come up with a proposal which would make sense from a business point of view for all parties involved, be it the amazing contributors to the WordPress project, the web hosts, the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme builders, the web agencies and the users who often run their business via their WordPress website.

In short, I’m proposing a fixed schedule in which every PHP version is supported for five years. Additionally each WordPress release will receive security updates for four years. In effect, this means that users, at a stretch, would be able to run on one specific PHP version for nine years.

A fixed schedule will make this whole process transparent and will allow all parties to plan for the version drops accordingly.

With Matt’s blessing, I’m posting this proposal here on Make to gauge the reactions of the wider community to my idea.

Please feel very invited to leave a comment whether you agree with the proposal or not.
Mentioning what your involvement is with WordPress and how this proposal will impact you in a positive or negative way, would be very valuable input for further discussions on this.

Chicken vs egg

The situation we are currently in, is basically one of “Which came first, the chicken or the egg ?”.

WordPress doesn’t drop support for older PHP versions until enough users have moved over to newer PHP versions and a significant enough share of the WP users don’t upgrade their PHP version until they really have to because WordPress drops support for the version.

This is circular logic, which as most developers know, never ends well as you end up in an infinite loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. where, in the end, neither moves forward.

So who are these users who don’t upgrade ?

Well, while we can’t know for sure, if we look at the figures, we can see some patterns:

Take note of the fact that the percentage of users on WP 5.1 who didn’t upgrade yet is relatively small and only part of that can be attributed to the PHP < 5.6 version drop in WP 5.2.

So let’s look at some likely personas for users who don’t upgrade:

We have the “zombie” persona, sites which are still online, but are not actively updated anymore.
These can be, for instance, sites which were linked to a specific event or other date-related topic which are still online for historical reasons, aggregate sites which automatically re-post from other sites without adminadmin (and super admin) involvement, or spam sites etc.

We have the “overwhelmed” persona, who blatantly ignores all admin notices. We all know why and how this happens. The multitude of notices in the admin area once a site has a few plugins and a theme installed trained this user to ignore them.

Then there is the “laid-back” persona, who has seen the notices, but doesn’t feel any urgency until they can’t update their site anymore.

And lastly, the “business” persona, often with a custom theme and a number of custom build plugins who’d rather move the costs of upgrading those to the next accounting year.

As for the user who feels out of their depth – amazing work has been done by the #site-health team to help those out.
For those users, I like to use the car analogy:

A website is something users will generally use regularly and expect to “just work”. So let’s make the comparison with something else a lot of people use regularly and expect to “just work”.

Say a car. Similar to WP, when one gets themselves a car, you need to familiarize yourself a little with how it works (interface/admin), but then it just runs. You put in petrol regularly (WP updates) to keep it running. Then once in a while, it needs a proper service. Now you have a choice: either you learn how to service a car yourself (read the site health materials and follow them up) or you go to a garage (hire a specialist) to do it for you.
And if you really don’t want to be bothered with all that, you lease a car instead (managed WP hosting solution).

Along the same lines: if you ignore the warning lights in a car (site health admin notices), you can’t pretend to be surprised that at some point it will break down (gets hackedhacked /can’t upgrade anymore). If was your responsibility as a user to act on them after all.

But Juliette, get to the point: how do you think we can get out of this situation ?

Ok, so here goes: I propose a fixed (rolling) schedule for dropping support for older PHP versions.

A fixed schedule means that such version bumps become predictable and with them becoming predictable, they become manageable and plannable.

These last two qualities are extremely important as all parties involved will know well in advance what they need to do and when it should be ready.

The current uncertainty over what WordPress will do leads to inaction, as we saw with two of the example personas, and we can counter that with becoming predictable and reliable with regards to the PHP version bumps.

So I propose that, as of now, we start dropping support for the PHP minor which is more than five years old each December, or if there is no release in December, in the WordPress release which is being worked on at that time.

That would currently look something like this, with the numbers at the top being the version of the WordPress release that December and the numbers at the bottom being the new minimum supported PHP version.

Keep in mind that, per the currently proposed schedule, the new minimum supported PHP version would always already be a version which is no longer actively supported by the PHP project, nor does it have security support anymore at the time it becomes the new minimum supported version for WordPress.

For example, PHP 7.1 was released in December 2016. Active support for PHP 7.1 stopped beginning of December 2018 and security support stopped on December 1, 2019. And based on the current proposal WordPress would still support it until December 2021.

But all those users on old WordPress versions…

Well, WordPress has always had a very liberal policy for backporting security fixes, so as part of this proposal, I’d like to suggest that the WordPress project makes a hard commitment to continuing to backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. security fixes for WordPress versions up to four years back.

What that would come down to in practice, is that if a user would always want to use the latest and greatest version of WordPress with the minimum of effort, they would need to ensure their PHP version is updated once every five years.

And if they don’t mind lagging behind a little in their WordPress version, they could even get away with only updating their PHP version once every nine years and still have their website running on a secure version of WordPress.

Now how does that sound ? Is that a liberal enough policy ?

Note: security fixes are currently back-ported as far back as WordPress 3.7. With this proposal, the minimum version of WordPress still receiving security fixes would not longer be a fixed version, but would change to a rolling number.

But what about the users currently on old WordPress versions ?

To solidify the commitment to making this as transparent as possible for the users, I propose we backport the PHP admin notice from the site-health project to the older, still currently security supported, WordPress versions, so that those users will be informed when they log in to their website.

Alongside of that we could ramp up the site-health notices based on this fixed schedule of version drops and committed security fix support.

So… what do you think ? I eagerly await the reactions of you all!

Props to @sergeybiryukov, @joostdevalk and @matt for looking this article over before publication.

#core, #core-php, #php, #request-for-comment