WordPress Should Bump PHP Support on a Transparent and Predictable Schedule

Juliette Reinders Folmer released a proposal for WordPress to drop old PHP version support on a fixed schedule. She wrote the proposal after Matt Mullenweg, WordPress co-founder and project lead, reached out to discuss solutions. This was after he closed a Trac ticket last week that sought to drop support for PHP 5.6 and bump the minimum version to 7.1 for the next major WordPress release this year.

The proposal lays out a position that many in the WordPress community could get behind. It is a clear-cut, transparent path for the platform’s future PHP support.

Folmer essentially put forward two roadmaps in the proposal. The first roadmap decides at what stage WordPress would drop support for a particular PHP version. The platform would remove support for a PHP minor release that is more than five years old each December. This would coincide with whatever major release of WordPress is upcoming. The following schedule lays out the minimum-supported PHP version each year:

  • December 2020 – PHP 7.1
  • December 2021 – PHP 7.2
  • December 2022 – PHP 7.3
  • December 2023 – PHP 7.4
  • December 2024 – PHP 8.0

The second part of the proposal creates a rolling schedule for backporting security updates to WordPress. Currently, WordPress releases security updates all the way back to the version 3.7 branch. If adopted, Folmer’s recommendation would support only the previous four years of WordPress releases.

Such a change would mean that when WordPress 5.6 is released in December 2020, the WordPress project would be committed to backporting security fixes as far back as WordPress 4.7, released in December 2016.

Folmer also proposes backporting PHP upgrade notices from the site health project to the currently-supported older versions of WordPress. This measure would inform users of PHP version issues before they make the jump to a newer version of WordPress.

The overlap of bumping the minimum PHP support into the future and backporting security fixes gives users a potentially huge window of nine years in which they could stay on whatever version of PHP they are currently on. Nine years may seem like a lifetime on the web with its constantly-changing technology, and it was a point of contention from some people in the comments of the post. However, it is a plan of action, something the WordPress community has not had the pleasure of experiencing with regards to PHP support. Developers will undoubtedly argue over the dates and versions, but that is secondary to actually having a predictable timeline.

A fixed version bump schedule is welcome. It puts everyone from developers to end-users to web hosts on the same page. This level of transparency is necessary if we ever intend to move forward without rehashing the same arguments.

The system of waiting around to see when a specific PHP version’s usage stats drop below a certain percentage just muddies things. The result is typically a long-winded argument that does not move the needle. Each side picks its stats. Each side digs its heels in. And each side has plenty of good points to make. Ultimately, everyone wants the same thing — to move the entire project forward and use up-to-date tools. However, they always disagree on how we get there. Eventually, the minimum PHP version gets bumped and the community gears up for the next round. It leaves us in a constant state of tug of war between those who want quicker advancement and those who do not want to leave users behind.

The truth is that no one is ever completely right in these arguments. There is no roadmap to follow. We have no guiding principle other than “this has what’s been done before.”

WordPress needs to set clear expectations.

This is not just a problem with the minimum PHP version — many want a more-detailed roadmap for the entire project. However, minimum PHP support is one problematic area that we could have a solution for, and Folmer has carved out a path. We need only follow it.

2

2 responses to “WordPress Should Bump PHP Support on a Transparent and Predictable Schedule”

  1. While I’ll again say that, in itself, I don’t see a problem with requiring updated dependencies to install a new version, as long as users are in no way forced or tricked into upgrading, there’s this bit:

    “Ultimately, everyone wants the same thing — to move the entire project forward and use up-to-date tools.”

    I for one want stability and control, to be able to keep using something I’m (more or less) comfortable with and know I have the possibility (but not the obligation) to apply updates fixing security vulnerabilities, and only those, whenever they appear, without worrying about any changes or incompatibilities brought by feature updates / new versions unless I specifically desire them, and to have full control of the software.

    Still give WordPress as the example of how to do it right, because of this continued backporting of security updates even on very old versions, without end of life and forcing people into feature updates… But the other side is pushing more and more to take it in the same rotten direction software has been heading in for the past decade or so…

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Discover more from WP Tavern

Subscribe now to keep reading and get access to the full archive.

Continue reading