No Minimum PHP Version Bump This Year, WordPress to Support PHP 5.6 for a While Longer

We should be leading the users, not following them.
We should be guiding the users, not coddling them.
We should carve out the road to the future, not continue to fix a broken road to the past.
We should say what we do and do what we say.

Juliette Reinders Folmer wrapped up her final thoughts on a ticket she had opened a mere three days ago. She had opened the ticket in anticipation of movement on WordPress’s minimum supported version of PHP. She had opened it after seeing the plan to no longer support PHP 5.6 in the WordPress 5.6 release plans (note that initial release plans are not necessarily set in stone).

There is no denying the symmetry of dropping support for PHP 5.6 with the release of WordPress 5.6. Fate seemed to be calling down, saying that it was time to move past the platform’s support of a version that reached End of Life in December 2018. It would be a nice sendoff, a farewell that could usher in a new era of maintaining some semblance of staying up to date with the latest and greatest the programming language has to offer.

But the excitement was cut short. WordPress developers, especially those who have longed for WordPress to be more proactive in updating its PHP requirements, will have to continue pushing for modernization into 2021. It does not look like it will happen this year.

Matt Mullenweg, WordPress co-founder and project lead, closed the ticket a few short hours after its opening. “Just so we don’t cherry-pick stats to make a point, it’s worth noting that the PHP distribution across all WP sites we track is the same as when that post was made in 2018: 85% are 5.6 or above,” he wrote. “Only about 66% are 7.1 and above.”

WordPress has required a minimum of PHP 5.6 since its version 5.2 release. Of the WordPress installs on versions 5.2 through the current 5.5 only 10.69% of those are running PHP 5.6, according to Sergey Biryukov, a core committer for WordPress. This percentage is even lower than when the team flipped the switch to PHP 5.6+.

“Given that we’re still releasing security updates for WP 3.7 (released almost 7 years ago), it’s not like we’re leaving PHP 5.6 or 7.0 users without security updates, they just won’t have some latest and greatest features of WP 5.6+, which seems fair,” he said in the comments on the WordPress 5.6 announcement.

“This is obviously a key philosophical decision that should be made by the project lead,” tweeted lead developer Andrew Nacin. “And for what it’s worth, our philosophies and standards on this have been consistent for more than a decade. The numbers strongly suggest it’s too early to drop PHP 5.6.”

While there are certainly arguments to looking at the data in different ways, one of WordPress’s guiding philosophies has been making the platform accessible to as many users as possible over the years. This has meant taking a slow, deliberate approach while also reaching out to web hosts and users alike. Dropping support for old versions of PHP has not been nearly as fast as some — including me — would like.

The need for updating the minimum version of PHP is not simply about developers wanting to use the newest and shiniest tools. There are practical concerns. PHP 8.0 is slated for release on November 26, 2020. Regardless of WordPress’s minimum required version, it must also work with the most up-to-date version of PHP. The wider the range of versions that the platform supports, the harder it is to test.

Such is the case with PHPUnit, a testing framework for PHP applications like WordPress. PHPUnit 8 supports a minimum of PHP 7.2. Technically, it has syntax that requires PHP 7.1 — hence, the need for the WordPress version bump. PHPUnit 9 requires a minimum of 7.3 and is necessary for testing PHP 8.0 compatibility. There is an open ticket for solving issues with PHPUnit testing where the team is exploring options to support the range of PHP versions.

“We also need to work on our messaging around these PHP and core upgrades, so we don’t cry wolf and cause these notices to be ignored,” continued Mullenweg in his explanation for closing the ticket, pointing to the current site health messaging in WordPress. “They do not say what version it is currently on. They do not provide a good way to contact the host. They do not give accurate information about security, as most hosts run backports that patch security on older versions separate from what is officially supported by the core PHP project. These are not free upgrades, and I think the cost vs what we are able to deliver to users, vs the hard caused by leaving so many people behind, needs to be seriously weighed. Right now it feels like we’re a bit trigger happy on these requirements, and I’d even be open to rolling some back.”

WordPress may be joked about in “real” programming circles. Its reliance on outdated tools may be the punchline from developers who are building sites with the Next Big Thing. However, maybe in spite of or maybe because of the platform’s reluctance to quickly drop support for older versions of PHP, it has swallowed up 38% of the web. Any project lead would question meddling too much with its leave-no-users-behind formula that was part of the journey getting here.

It is a tough call for a project lead to make. It is also tough because developers like Folmer have put a ton of work into PHP coding standards tools and do the often thankless job of advocating for pushing WordPress into modern-day coding practices.

WordPress is in a position where it has some leverage. If the software demands an upgraded PHP experience, it can put its massive user base to work by forcing web hosting companies to cater to their needs. Money talks, and if enough users begin looking for greener pastures, perhaps those web hosts will make some adjustments. That is at least the theory that some in the community share. “If there are no consequences to user/host (in-)action, why would they ever bother to take action?” asked Folmer.

It is also a gamble that the WordPress project does not look to be taking, at least for the version 5.6 release.

18

18 responses to “No Minimum PHP Version Bump This Year, WordPress to Support PHP 5.6 for a While Longer”

  1. My question here would be: “Are we trying to build the best WordPress we can, or are we more concerned with powering 38% of the web?”

    Not all hosts provide updates to php (or MySQL – mine doesn’t, I’ll be leaving them at the end of the year) but I don’t think WordPress should be in the business of supporting hosts who haven’t updated for the last seven years because they don’t care. I guess I agree with Folmer; we should be driving on.

  2. It is 100% the right call. There’s enough going on in the world right now not to mention the breaking changes in PHP8.

    Even Windows won’t be supporting PHP 8. I’m not sure how that affects WordPress — how many are on Windows Servers, but it’s an issue for sure.

    “We are not, however, going to be supporting PHP for Windows in any capacity for version 8.0 and beyond.” Dale Hirt, Service Engineer Microsoft

    https://externals.io/message/110907

  3. I don’t get it. The 15% have had plenty of time to move up. Why are we focusing on waiting for them? Too bad.

    I’ve been upgrading over 300 client sites for awhile now. Totally disagree with this decision to put this on hold.

  4. Bridget, it is not about this call, it is about the trend. Each call by itself might be justified, the trend in which users are encouraged to use unsecure platfoms for years after the publically became unsecure is a different thing.

    As for PHP on windows, good job of getting things out of context. I am sure you didn’t intend too but that exactly what you have done. microsoft will not be releasing PHP for windows which is the same as linux not releasing PHP for linux, a fact that never prevented anyone to run wordpress on linux.

  5. Those first two lines, the first one in particular, sure spell out a major part with what’s wrong with software development in recent years…
    Admittedly, as long as security updates continue to be provided for old versions, I do agree that it’s not really a problem, and those who specifically want the newest features should probably be expected to also stay reasonably up to date in other aspects as well. But that’d also require WP not pushing for major version updates in the manner it does either, so less savvy users won’t find themselves updating (or even automatically updated) to the newest WP without really meaning to.

  6. The core issue for me is not whatever PHP version WP supports. What has changed since the release plans? Where is the Make Core blog about this change? If nothing changed, why was there no action taken on this before the release plans were published?

    It’s a lack of comms / transparency, I think.

  7. I don’t think WordPress should have a minimum PHP version that has reached end of life 2 years ago. WordPress says users should always update to latest version for security and so forth then WP it self should also update versions.
    We saw what not updating dependencies regarding jQuery led to.
    If people know that WP will always have a minimum PHP version support that is say 3 releases behind PHP latest then everyone knows what to expect and can plan for it. The current method is to random from the outside looking in.

  8. Why is the decision made on the fly each time?

    It seems the main argument for not upgrading is that hosts that haven’t upgraded yet – for whatever reason – will suffer, and so will their customers. This is only a real argument because the decision gets made so close to the release, so it would come suddenly.

    The way to do this is to publish a plan well in advance – say, six months – that says, “In WordPress 5.x, we will be dropping support for PHP 5.” Make sure everybody knows it’s coming and has time to move. You put this information in the Dashboard of successive WordPress versions, so everybody knows it. Then when you reach the day, you follow the plan as promised.

    Each time WP makes the decision not to do it right now, without instead saying when that day will be, it reinforces the idea that hosts don’t need to upgrade yet.

  9. If WordPress, themes and plugins would only support the latest versions of PHP, let’s say the 7 serie. Then less rows of code are needed because all deprecated code can be removed. The codebase would decrease and code will be more stable and easier to maintain.

    Or am I seeing this wrong?

  10. Sorry guys! As a Woocommerce Store owner, I find this entire exercise ridiculous.

    Site Health keeps displaying an annoying recommendation to upgrade to PHP 7.4. There are no controls in place to check if all plugins in WordPress repository are fixed to work with PHP 7.4

    Please understand that as Store Owners we would rather focus on our business than keep tinkering under the hood to just keep things working!

    And please do not be patronizing and tell us to hire a developer / some agency to do this for us.

    Thanks

  11. Hey WP folks, I think there are a lot of important circumstances overlooked here when it comes to the talk of the wb hosts. I work at a small managed web host, catering to hundreds of non-profits and charities. I find the part at the end about forcing the web hosts to comply to be quite alarming! … as it’s not actually their fault or something they can fix most of the time!

    On the host side of the euqation, we have all moved on to PHP 7 long ago (2 Debian versions ago for us). Yet the majority of our older WP customers are stuck on PHP 5.6 because they haven’t the budget or the slightest understanding of what’s involved for a successful upgrade.

    The PHP upgrade notice dialog is totally unhelpful as it mischaracterizes the problem as a security issue (unless someone is compiling old PHP from upstream source, it’s not, PHP is running with backported fixes from a distro security team and is arguably more secure than when it ships from php.net in the first place).

    Anyway, about 90% of the time when a customer contacts us about the message and we go through the correct safe proces to update (see below) we discover that their site would have been broken if we had just changed the PHP version!

    So here’s the actual problem, what commonly breaks when you upgrade PHP 5.6 to PHP 7.1+ on a wordpress site is all the expensive stuff:

    Premium plugins that were purchased years ago and never updated regularly, these do not support PHP 7 coding standards and break horribly. This is hugely common.
    Solution: is to pay for each of these again and upgrade them ($ for plugins and $ for developer time to do the work, plus some kind of dev/stage environment if the developer can’t provide that themeslves)
    Problem: info on the correct solution, the cost, and competant dev help are a barrier to entry
    Custom code in theme or chld theme. Those snippets that finally worked that the old developer copied into functions.php from some stackoverflow answer 5 years ago? The code the part time student thrashed together that one summer for cheap? That code the marketing person made work that the support people gave them? These are the types of things that will be broken in PHP 7. They may spew warnings, or worst case cause fatal errors and dead pages, or prevent the site loading altogether.

    Solution: Debug the problem starting at the error_log entries and working back.

    Problem: barrier to entry finding developer: debugging old code is harder than writing new code, the work is beyond horrible and no one who isn’t desperate will touch it with a 99 foot pole, due to its complexity the work needs a more senior developer willing to do that awful work, these people are hard to find and expensive.

    Custom plugins. This indicates more serious development skills when first built, but when it comes to debugging problems that’s usually a curse and not a blessing. Now the problem of the above point is abstracted and confusing to reverse engineer, plus it likely relies on ancient / obselete / insecure frameworks or libraries that also need to be upgraded to modern versions in order to fix them (which then triggers a chain reaction of destruction throghout the rest of the dependencies). It can be cheaper to rewrite than to fix these, at the cost of a bunch of functionality. A painful sacrifice for the customer to make. Again, that is if someone is supporting them hand holds them through all this… otherwise they just ask their host to update PHP and often that’s a one way change they can’t undo and their site is wrecked, game over.

    Depending on the size of the site, and taking into account the work involved to successfully test and fix in an offline instance of the site, an organization can often be looking at thousands of dollars even if things go well.

    So! Let’s please not all get our burning torches and march down to the web hosts front door just yet… this isn’t their falut and it’s not their problem. Most of them could activate PHP 7 everywhere at the flip of a switch. They are more aware than most people about internet security and so they would love to be able to do so if it didn’t almost always completely destroy their customers sites (and thereby livelyhoods). So ironically except for bad ones (below) it’s the ones that give a crap about their customers who aren’t doing so automatically in a lot of cases. Forcing it on the users is the easy solution for the hosts but the results for users would be disastrous!

    And yes it’s true there is a lot of bad infra out there that is dangerously out of date and EOL, where it is the host that is the blocker! But often the host is not selling upgrades or support in those cases and it’s $5 hosting… Even more common than that is where someone back in the day had the bright idea to admin their own VPS without being a provessional (I wonder if they fix their own car and do their own plumbing and electrical too? things that make you go hmmmm!!??). This can be fixed or migrated away from but is more specialty help, then all the above points still apply.

    Anyway, what the wordpress developer community should be doing IMO is addressing this issue by educating users and connecting them up with developers (who must help with their part of the problem by fixing other random developres stinky obselete code). The end result of which, for our selfless heroes, will be a new ongoing wordpress maintenance & dev client….. because you are going to explain about maintenance and security updates to them and not let them get co-opted into a giant botnet right? :-)

    sincerely,
    a caring webhost who wants to get rid of PHP 5.6 even more than you!

Newsletter

Subscribe Via Email

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