PHP: bump minimum version requirements

[jrf]

As discussed in the ​May 11th Site Health meeting (​Slack logs) and announced in the ​WP 5.6 release planning support for PHP 5.6 will be dropped in WP 5.6.

This ticket is specifically to handle this version bump.

The target PHP minor is PHP 7.1 as that version will allow us to upgrade the test suite to be compatible with PHPUnit 8.x and 9.x, which is necessary to be able to test WordPress against PHP 8.
Ticket #46149 is in place to address that and has a patch ready to be committed.

I propose we bump the minimum supported PHP verson to PHP 7.1.26.

Reasoning to choose this specific version:

• 80% of 7.1 sites are on 7.1.26 or higher.
• PHP 7.1.26 has less than 20 known security vulnerabilities.

Sources:

• ​https://w3techs.com/technologies/details/pl-php/7.1
• ​https://www.cvedetails.com/version-list/74/128/2/PHP-PHP.html?sha=78e084dbc6897971bd02e634619a193e623904d6&order=1&trc=1128

Opinions welcome on the specific patch version choice.

The version bump itself should be regarded a foregone conclusion.

To quote @sergeybiryukov:

We only need to look at the recent WP versions here (5.2 to 5.5), for those the PHP 5.6 percentage is currently 10.69%, which is lower than the 12.11% percentage of PHP <5.6 for WP 4.9 to 5.1 just before the WordPress 5.2 release (May, 2019), where support for PHP <5.6 was dropped.

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.

Source: ​https://make.wordpress.org/core/2020/08/13/wordpress-5-6-release-planning/#comment-39483

Tickets related to previous version bumps:

• #46594 - WP 5.2 bump of minimum PHP version to 5.6
• #16917 - WP 3.2 bump of minimum PHP version to 5.2

[jrf]

This patch bumps the minimum PHP version to PHP 7.1.26. The Travis and test run changes will be addressed in #46149

[desrosj]

Though I am not at all against this change, I think a follow up to the ​original proposal to begin raising minimum version support specifically detailing the reasoning and numbers behind this decision is warranted before making the change.

Trac is monitored regularly by very few people, so this would begin the communication process and serve as a last call for feedback and help identifying any edge case issues that have been missed.

[jrf]

@desrosj I'm happy to create a post about this, though IMO this ticket should not depend on the feedback to the post. The task is in the WP 5.6 release planning announcement and the feedback regarding the version drop there has been mostly positive in the comments, and more so even on social media, so it's not as if people haven't taken note.

[desrosj]

Sorry, didn't mean to imply that the feedback on that post would hold up this ticket, or prevent this bump from happening. It's more to make everyone aware that the steps for the next phase of that plan are being put in motion, and to catch any steps missed.

Documenting what metrics were at the time of the decision to finally make this change is also important for historical reference.

Publishing a post titled "Raising Minimum Version of PHP" will also just catch more attention that a bullet point in the proposed release features/changes and a note in the weekly meeting summary.

[joostdevalk]

100% in favor of this, as expected probably, but still wanted to voice that :-)

[matt]

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. Only about 66% are 7.1 and above.

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

Going to close for now, on other P2s or it would be great to continue the discussion on the 21% of sites on 5.6 or below and what we could do to help get them upgraded before moving the finish line again.

[jrf]

@matt Do I understand you correctly in that you are basically prioritizing supporting PHP 5.6 - which is outdated and has no security support anymore - over supporting PHP 8.0, which is due to come out just before WP 5.6 ?

I just want it stated for the record that in that case, PHP 8.0 support will not be a realistic goal in the foreseeable future.

[SergeyBiryukov]

As noted in the ticket description, bumping the required version to PHP 7.1 is necessary to support PHPUnit 8.x or later (#46149), which is instrumental in PHP 8 support, which in turn, being released on November 26, 2020, is also one of the focuses for WordPress 5.6.

I also don't think we need to look at the PHP usage for *all* WP versions here, as those on WP <5.2 are unlikely to update WP or PHP. I believe we only looked at WP 4.9 to 5.1 when bumping the requirement in WP 5.2, and I think we should do the same here.

If we look at the recent WP versions (5.2 to 5.5), 78.52% of those are already on PHP 7.1 or later (as opposed to 66% for all WP versions). That means only 21.48% of those are on PHP 5.6 or 7.0. That is still high, but could be brought down to a more acceptable number by the end of year with some brainstorming and coordinated efforts between Site Health and Hosting teams. Just closing the ticket doesn't seem productive for anyone :)

[SergeyBiryukov]

For the last 5 years, ​starting with PHP 7.0, WordPress has been aiming to get ready for the latest stable PHP version at the time of launch. I don't see a reason to break that precedent with PHP 8.

[justlevine]

What's the usage for 5.6 and 7.0 separately? Iirc the migration from 7->7.1 was negligible compared to 5.6->7, so beyond the great points @SergeyBiryukov made it's possible were 'leaving behind' a lot fewer sites than we think.

[SergeyBiryukov]

Replying to justlevine:

What's the usage for 5.6 and 7.0 separately? Iirc the migration from 7->7.1 was negligible compared to 5.6->7, so beyond the great points @SergeyBiryukov made it's possible were 'leaving behind' a lot fewer sites than we think.

For WP 5.2 to 5.5, 10.69% on PHP 5.6 and 10.79% on PHP 7.0.

It's also worth noting that the "minimum acceptable" PHP version was bumped from 7.0 to 7.2 only two months ago, see ​#meta5257. In these two months, PHP 7.0 percentage for WP 5.2 to 5.5 has dropped from 12.44% to 10.79%. So it seems a bit too early to come to the conclusion that the current measures are ineffective.

[ayeshrajans]

PHPUnit maintainer has mentioned that PHPUnit 9.3 will be the only version that supports PHP 8.0, and I think it is a good call on Sebastian because the sheer amount of changes in PHP 8 that makes it quite difficulty maintain at the size of PHPUnit.

7.1 is a good compromise between supporting old versions and adding PHP 8 support. I'm sure @jrf has spent a lot of effort in finding the right balance.

In comparison, Drupal and Symfony, which often maintains support for older PHP versions for a quite while (Drupal 7 still supports PHP 5.2 for the most part), have moved to a PHP 7.1 and 7.3 minimum versions.

WordPress 5.4 + 5.5 usage is about 48%, which I believe the expected percentage of those who will eventually upgrade to 5.6. On the PHP stats front, PHP 5.6 and 7.0 usage is 25.5% in total. This means that realistically, and using likely unfair math, we will be leaving ~12% of users behind who might upgrade to WordPress 5.6, but still have an older PHP version.

I'm not a decision maker for WordPress, but as a contributor, I'm all in support for this version bump. This also opens up a whole new world of opportunities to make this change worth it in terms of security, performance, and code maintainability.

[ZanderZ]

Replying to jrf:

[...] the feedback regarding the version drop there has been mostly positive in the comments, and more so even on social media, so it's not as if people haven't taken note.

To be honest, when I first saw the announcement I thought it was a typo since it was just one of several bullet points. It was the PHPUnit ticket that I've been following for months that told me this was really happening.

I would be very disappointed if this PHP version bump didn't go through. Having PHP 7 as the minimum version would mean core and plugins could finally use return type declarations, type hints, etc. Something we've been able to use in our own codebase since 2015!

[williampatton]

Reopening this ticket and marking for Future Release. What is in question here is when this happens and how we handle it - but there is no questioning that this should happen at some point.

[matt]

I think we all agree that we want people on the latest and greatest versions of PHP, MySQL/Maria, and WordPress itself — it makes everyone's lives a lot easier.

If we want to do this we need to figure out how we can work with hosts, contact users or sites, and otherwise find other tools in addition to site health to get these PHP versions below 5% usage or close to it so we can drop support. Profiling which hosts are hosting the 22% of sites on 5.6 or below would be a good start.

Don't want to overload this ticket, which as @williampatton puts I think will be great for some future release.

[jrf]

Well, in my opinion, the issue is simpler:

Do we want to prioritize the 20-30% of users who don't upgrade over the 70%+ of users who do ?

With this change, users who don't upgrade can still use WP, just not the latest features/latest release.
They still get security patches and such, so they can continue as if nothing has changed.

Without this change, users who *do* upgrade will not be able to use PHP 8.0 as it will cause site-wide outages and a galore of white screens of death, which we will not be able to properly solve and safeguard against without making this change.

[jorbin]

As has been discussed on #46149, there doesn't appear to be a need to sacrifice support for PHP8 even if we can't upgrade the minimum. Yes, core can't take advantage of some of the new language features, but we have thus far been able to build software used by 38% of the internet without them.

[stuffradio]

I support bumping min php version to 7.1.

[SergeyBiryukov]

For reference, the "minimum acceptable" PHP version (sites with a version lower than this will see the dashboard widget urging them to update) in ServeHappy API was previously bumped:

• From 5.6.20 to 7.0 in ​#meta4671 (a year ago)
• From 7.0 to 7.2 in ​#meta5257 (two months ago)

Within the last year:

• PHP 5.6 has reduced from 28.59% to 14.97%.
• PHP 7.0 has reduced from 15.79% to 10.37%.

These results actually look pretty good, the percentage is noticeably decreasing, just not fast enough for WP 5.6.

If the trend continues, I think both versions can get below 5% in the next 12 months.

[jrf]

Thanks @SergeyBiryukov For adding that information. Good to see there is progress.

[jrf]

I'm closing this issue now and changing the meta information to reflect the reality.

I never opened this as a "feature request" or because I wanted this change (which I do, but that's besides the point).
I opened it because it was announced as one of the tasks in the WP 5.6 release planning and after consulting with other core contributors about the timing.

Clearly the release planning is not a trustworthy source of information if it can be so easily be overruled without consulation with the release squad.

I'm also setting this to "won't fix" as that is evidently the current standpoint. If at some point in the future (outside of the WP 5.6 release cycle) that standpoint should be challenged again, I suggest someone else opens a new ticket. Please do not reopen this ticket as the stats and others figures in this ticket will no longer be accurate or relevant.

As to the question of why the site health project and the warnings/upgrade recommendations are not effective enough: Decisions like this are the reason.

For the WordPress project to usurp the responsibility of the users is patronizing and, to be brutally honest, stupid.

If there are no consequences to user/host (in-)action, why would they ever bother to take action ?

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.

We, the contributors and leadership of the WordPress project, are to blame by accepting decisions like this.

[johnjamesjacoby]

I believe strongly that the greatest strength of WordPress is its diversity – in authorship & contributorship, and in the multitude of allowed server configurations that it will gracefully run on and in.

The fact that changes are required to WordPress to support PHP8 and PHPUnit is either a problem with PHP, PHPUnit, or the ways WordPress has decided to integrate with them.

If it is true that PHPUnit 9.3 is required to test PHP 8, and if our reaction to that is largely a negative one (as has played out above) then WordPress dropping support for legacy PHP versions is simply passing our pain onto our users, making them feel how we've felt. Why would we do that on purpose?

It must be possible to bump the minimum version as needed without abandoning existing users. That's the challenge being presented to us here, and is one we have seen in the past and will see repeatedly in the future.

Rather than talk past each other through frustration, let's lead by example and find a common ground to leap off of and solve this problem together in a way that satisfies all requirements (including happy users). ❤️

[jb510]

Replying to matt:

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. Only about 66% are 7.1 and above.

As respectfully as possible... this is literally the definition of cherry picking stats. Stats do matter, so let’s have a reasonable conversation about what’s behind these stats and and where the blind spots are.

I feel the most important stat to consider would be what percentage of those site running PHP 5.6 and below, that are also running the latest version of WP (5.4 or 5.5 since 5.5 is still so fresh). That’s about 50% today. That would be a more accurate proxy as to how many sites would be affected by WP 5.6 dropping support for PHP 5.6 rather than implying all sites are affected equally.

Sergey mentioned the serve happy notice, cool, but how many see that? Tthere are so many sites folks don’t actively manage and no one is ever going to see that notice. I think there is a fundamental ignorance of the fact that there are a lot of ghost ships out there sailing the seas of the Internet. Sites which no admin has logged into in years. In some cases sites admins have forgotten these sites even exist. No one is ever going to upgrade WP on those, let alone PHP. I still log into servers on a regular basis to find long abandoned WP installs still chugging away in some forgotten sub folder. Less so today than 5 years ago, but I still find them.

Even more conservatively, let’s say “actively maintained” is the 75% of sites which run WP 5.x, leaving 25% running WP 4 or below. what percentage of that 75% chunk would be affected be dropping PHP 5.6?

I suspect viewed through the lens of “active sites”, even the generous 75%, that very few sites running PHP 5.6 would be affected by this. While the benefit to the site owners and further To the ecosystem of developers continuing not having to jump through hoops to accommodate dead versions of PHP far out weighs the cost to those abandoned ghost ships.

[matt]

Thank you for the feedback @jb510, it's definitely true that if you decide some of those sites aren't active or relevant, it doesn't feel like such a big deal to leave them behind. But even if you slice it super narrowly and take just sites on WP 5.4 or 5.5, that have pinged within the past two months, and running PHP 5.6... that's still more than 1.2 million sites. One million is hard to visualize, but ​Builtwith tracks about half a million Drupal sites, so imagine two whole Drupals worth of sites being unable to upgrade because of a choice we made, which is something to consider very carefully.

As an update, I wanted to thank @jrf for hopping on a call with me yesterday. I think we both understand each other a lot better, and I felt like we're in strong agreement that WP should support PHP8 before it's released, that we both want people on the latest and greatest versions of WP and PHP. I also have a better understanding of the places we differ, for example in dropping support for prior PHP versions on a time-based schedule versus a hurdle-based approach. She shared a great presentation advocating for a time-based approach and I asked for it to be shared on the make/core P2 as well which I believe is going up soon.

I appreciate her taking the time to talk, and it's a good reminder that we can debate ideas and direction vigorously while not making it about the person, we should always search for deeper understanding, and we can disagree and commit and still work together the next day.

[jrf]

it's a good reminder that we can debate ideas and direction vigorously while not making it about the person, we should always search for deeper understanding, and we can disagree and commit and still work together the next day.

Hear, hear!

For those interested, the proposal Matt and me discussed is now public for everyone to peruse and comment on:
​https://make.wordpress.org/core/2020/08/24/proposal-dropping-support-for-old-php-versions-via-a-fixed-schedule/

[SergeyBiryukov]

Related: #33381

[snoringdragon]

Replying to jrf:

it's a good reminder that we can debate ideas and direction vigorously while not making it about the person, we should always search for deeper understanding, and we can disagree and commit and still work together the next day.

Hear, hear!

For those interested, the proposal Matt and me discussed is now public for everyone to peruse and comment on:
​https://make.wordpress.org/core/2020/08/24/proposal-dropping-support-for-old-php-versions-via-a-fixed-schedule/

Hi, sorry for bothering you but can you tell me what was the result of that proposal?

It’s been around 4 years since wordpress last increased its minimum PHP requirement.
Make post => ​https://make.wordpress.org/core/2018/12/08/updating-the-minimum-php-version/
At that time, only 85% websites were using PHP version 5.6 or higher but wordpress still decided to increase its minimum PHP requirement to 5.6 for security and performance reasons.
But now, as per wordpress statistics, only 5.8% wordpress installations are currently running on PHP version 5.6.
I think we are now ready to further increase minimum PHP requirement to 7.0.
With proper coordination with hosting companies and encouraging the sites to increase PHP version to 7.0 by showing message in WordPress 6.1, we will be able to further decrease that 5.8% statistics.
We can target wordpress version 6.2 for this change but we should make a proposal on make blog and try to include message that wordpress version 6.1 will be last version to support PHP version 5.6.
This change will allow wordpress to enhance the security while at the same time get rid some bloat from core, improving the performance. I think this will also pave the way for some good new feature
such as ​https://github.com/WordPress/performance/issues/427.
Thanks for your time.

[jrf]

@snoringdragon This is an old issue. Please do not reopen.