Bump the minimum required PHP version to 7.0

[SergeyBiryukov]

Background: #16917, #33381, #46594, #51043.

Per discussion in #51043, specifically comment:16:ticket:51043 and comment:26:ticket:51043, for WordPress to consider dropping support for PHP 5.6 or 7.0, these versions need to get below 5% usage, regardless of the WordPress version used on those sites.

As of 17 Dec 2022, that happened:

• PHP 5.6 is at 4.99% of all WordPress sites
• PHP 7.0 is at 2.68%
• PHP 7.1 is at 1.82%

Per discussion with @azaozz, this means we can bump the minimum required PHP version. We're going to aim for 7.0, not 7.2 as previously discussed on this ticket.

This ticket aims to determine the specific minor PHP version in the 7.0 branch to bump to, as well as to track any other tasks related to the bump.

Previously:

• #46594 Bumping the minimum PHP version to 5.6 in WordPress 5.2
• #16917 Bumping the minimum PHP version to 5.2 in WordPress 3.2

[JavierCasares]

This is something we talked a lot in the Hosting Team, so, +1 for me. :)

Deprecating PHP 5.6 has always a goal for the Hosting Team, and PHP 7.0 and 7.1 never had the adoption as PHP 7.2.

Trac ticket: https://core.trac.wordpress.org/ticket/57345

[mukesh27]

Thanks, @SergeyBiryukov for the ticket. I have submitted a PR to bump the minimum required PHP version to 7.2.

composer.json should also be updated:

​https://github.com/WordPress/wordpress-develop/blob/trunk/composer.json#L12-L14

[audrasjb]

Thanks for the PR!
We should probably update this line in phpunit.xml:

	<!-- WordPress Core currently supports PHP 5.6+. -->
	<config name="testVersion" value="5.6-"/>

We should probably update this line in phpunit.xml:

I presume you mean in phpcompat.xml.dist ?

IIRC, there is a file related to the site health component which should also be updated.

The previous patch should give some indication of what's needed: https://core.trac.wordpress.org/attachment/ticket/51043/51043-php-version-bump.patch (though of course the repo has moved on, so there will likely be more places now in which changes are needed)

[costdev]

The last minor in the PHP 7.2 branch is ​7.2.34.

@SergeyBiryukov, do we have data on PHP 7.2 minor usage? If so, we could just start from the first 7.2 minor with 5%+ usage.

Now that the minimum PHP version has been raised, the test workflows should not run against earlier PHP versions.

This change removes references to PHP versions lower than 7.2 from the GitHub workflows.

Trac ticket: https://core.trac.wordpress.org/ticket/57345

Now that the minimum PHP version has been raised, this test and its data provider can be removed.

The datasets from the data provider have been relocated to other data providers in the test class.

N.B. This PR has expected test failures in PHP 5.6 tests until #3782 is merged.

Trac ticket: https://core.trac.wordpress.org/ticket/57345

is_iterable() was introduced in PHP 7.1.

Now that the minimum PHP version has been raised, the is_iterable() polyfill and accompanying tests can be removed.

Ref:

• PHP RFC

​https://wiki.php.net/rfc/iterable

• PHP manual is_iterable()

​https://www.php.net/manual/en/function.is-iterable.php

Trac ticket: https://core.trac.wordpress.org/ticket/57345

The IMG_WEBP constant is defined in PHP 7.0.10 and later.

Now that the minimum PHP version has been raised, the IMG_WEBP constant definition can be removed.

Ref:
PHP manual - Migrating from PHP 5.6.x to PHP 7.0.x
​https://www.php.net/manual/en/migration70.constants.php

Trac ticket: https://core.trac.wordpress.org/ticket/57345

The IMAGETYPE_WEBP constant is defined in PHP 7.1 and later.

Now that the minimum PHP version has been raised, the IMAGETYPE_WEBP constant definition can be removed.

Ref:
PHP manual - Migrating from PHP 7.0.x to PHP 7.1.x
​https://www.php.net/manual/en/migration71.constants.php

N.B. This PR has expected test failures in PHP 5.6 and 7.0 tests until #3782 is merged.

Trac ticket: https://core.trac.wordpress.org/ticket/57345

The random_compat library polyfills functions from the Random PHP extension in PHP 7.x to PHP 5.x. Random is a core PHP extension, and will be included in all PHP binaries.

Now that the minimum PHP version has been raised, the random_compat library can be removed.

This change also removes the inclusion of random_int() in wp-includes/compat.php.

Ref:

• PHP manual - Membership - Core Extensions

​https://www.php.net/manual/en/extensions.membership.php

• Paragonie/random_compat GitHub repository

​https://github.com/paragonie/random_compat

N.B. This PR has expected test failures for PHP 5.6 tests until #3782 is merged.

Trac ticket: https://core.trac.wordpress.org/ticket/57345

[costdev]

I've submitted PRs for the following "cleanup" tasks:

• ​PR 3782: Remove < PHP 7.2 test workflows. Superceded by additional commits in ​PR 3779.
• ​PR 3783: Remove PHPUnit test condition related to PHP version < 7.
• ​PR 3784: Remove ​the is_iterable() polyfill, as is_iterable() was introduced in PHP 7.1.
• ​PR 3785: Remove ​the IMG_WEBP constant definition, as this constant is defined in PHP 7.0.10+.
• ​PR 3786: Remove ​the IMAGETYPE_WEBP constant definition, as this constant is defined in PHP 7.1+.
• ​PR 3787: Remove ​The entire random_compat library which polyfills functions from PHP 7.x to 5.x. Random is ​a core PHP extension.

If desired, I'm happy to move these PRs to individual tickets after this one is committed though.

Superceded by additional commits in #3779.

Thanks for the update @mukeshpanchal27 ! Line 65 of the yml file still needs to be removed (split_slow in the matrix definition).

[jrf]

Replying to costdev:

The last minor in the PHP 7.2 branch is ​7.2.34.

@SergeyBiryukov, do we have data on PHP 7.2 minor usage? If so, we could just start from the first 7.2 minor with 5%+ usage.

I don't have access to WP specific data, but based on world-wide usage, PHP 7.2.24 would be a good version to set as minimum:
​https://w3techs.com/technologies/details/pl-php/7.2

The CVE version listing looks to be grossly out of date: ​https://www.cvedetails.com/version-list/74/128/1/PHP-PHP.html so it may be harder to determine which version to choose based on known vulnerabilities.

[jrf]

Replying to costdev:

I've submitted PRs for the following "cleanup" tasks:

If desired, I'm happy to move these PRs to individual tickets after this one is committed though.

I think that would be a good idea.

[costdev]

Thanks @jrf! I'll wait to see if ​PR 3779 is committed and if so, I'll open separate tickets for at least some of the above PRs I've submitted. 🙂

[SergeyBiryukov]

Replying to costdev:

The last minor in the PHP 7.2 branch is ​7.2.34.

do we have data on PHP 7.2 minor usage? If so, we could just start from the first 7.2 minor with 5%+ usage.

Yes, I have collected the ​stats for PHP 7.2.x usage across all WordPress sites.

This spreadsheet is similar to the stats previously shared in comment:2:ticket:46594 for PHP 5.6.x, with a notable difference that the latter was limited to WP 5.x. We could probably limit the PHP 7.2.x data to WP 6.x, but I have not yet figured out where the PHP stats for a particular WP version are stored.

Based on the above:

• 94.78% of all WP sites using PHP 7.2.x are on 7.2.24 or later.
• 95.74% of all WP sites using PHP 7.2.x are on 7.2.20 or later.

Would 7.2.20 be a good candidate? I see comment:22 mentions 7.2.24, that seems like a good option too.

[costdev]

@SergeyBiryukov Given the 5% threshold, I think 7.2.22 is probably the "safe" option, unless 7.2.22 has been getting dropped in favour of 7.2.24 quickly in recent months and is expected to be under the 5% threshold by the time WordPress 6.2 is released.

[jrf]

Replying to SergeyBiryukov:

Replying to costdev:

The last minor in the PHP 7.2 branch is ​7.2.34.

do we have data on PHP 7.2 minor usage? If so, we could just start from the first 7.2 minor with 5%+ usage.

Yes, I have collected the ​stats for PHP 7.2.x usage across all WordPress sites.

This spreadsheet is similar to the stats previously shared in comment:2:ticket:46594 for PHP 5.6.x, with a notable difference that the latter was limited to WP 5.x. We could probably limit the PHP 7.2.x data to WP 6.x, but I have not yet figured out where the PHP stats for a particular WP version are stored.

Based on the above:

• 94.78% of all WP sites using PHP 7.2.x are on 7.2.24 or later.
• 95.74% of all WP sites using PHP 7.2.x are on 7.2.20 or later.

Would 7.2.20 be a good candidate? I see comment:22 mentions 7.2.24, that seems like a good option too.

Thanks for collecting that data and setting up the spreadsheet @SergeyBiryukov !

IMO either are a viable option, but there are other aspects to take into account for which no information has been added to this thread yet:

• Security considerations - which PHP 7.2 version is a reasonable candidate given publicly known security vulnerabilities in various PHP 7.2 versions ?
• Bug fixes - I think the ​changelog of PHP 7.2 will need to be scrutinized to verify if there are any critical bug fixes which should be considered a "must have" and in which PHP 7.2.x patch version those were included.

We should probably update this line in phpunit.xml:

I presume you mean in phpcompat.xml.dist ?

Yeah sure 👍

[azaozz]

Per discussion with @azaozz, this means we can bump the minimum required PHP version

Yep, we talked about bumping it (about a month ago?) but don't think all the conditions are met yet. Generally the conditions are as follows:

1. The number of sites that will be "left behind" (on less than the new min version) have to be less than 5%, not 5% per PHP version. Currently that number is about 8.5% if excluding old WP sites that are on even older PHP versions.
2. Even if the above number was at 5% or below, 6.2 is far too soon to bump the minimum PHP version. What usually happens when WordPress announces PHP version bump is that hosting companies start to move WP sites to newer PHP versions. However that takes time. So these announcements should be made well ahead of the cut-off date.
3. After the above conditions are met, a final decision about the cut-off date can be made and be approved by the project leadership.

In that terms think this ticket should be milestoned to "future release", not 6.2.

[JavierCasares]

Yep, we talked about bumping it (about a month ago?) but don't think all the conditions are met yet. Generally the conditions are as follows:

But, are really those numbers real? Or are they ghosted sites? This is something that we usually talk in the Hosting team meetings. To be accurate, the real data should be “WordPress major version + PHP major version” (if this data exists, I didn't find out).

If you have WP 3.9 + PHP 5.6, that's a ghost site… and this should'b be counted.

If you have a WP 6.0 + PHP 5.6, that's a problem site… and this need to be counted.

I asked some time ago for this data, but couldn't get it to analyze with the others Hosting Team Reps.

The real question here is… should we check WordPress older than WP 4.0 (for example) whatever PHP have?

If you have some older versions of WordPress, and you want to update, you don't need to update WordPress only you need to update everything. For that reason, we created this post: ​https://make.wordpress.org/hosting/handbook/upgrading/

[hellofromTonya]

Replying to azaozz:

don't think all the conditions are met yet. Generally the conditions are as follows:

1. The number of sites that will be "left behind" (on less than the new min version) have to be less than 5%, not 5% per PHP version. Currently that number is about 8.5% if excluding old WP sites that are on even older PHP versions.

I think we can all agree that bumping the minimum supported PHP version is needed. But the criteria to do a bump has not yet been met. I agree with @azaozz. The user data < 5% (as noted) is a must-have requirement set by Matt. 8.5% is really close, but not yet less than 5%. Continuing to help users upgrade off of old versions will help to drive the numbers down.

Once the numbers are low enough, then I also agree with these steps @azaozz identified, i.e. before doing the work in Core.

2. Even if the above number was at 5% or below, 6.2 is far too soon to bump the minimum PHP version. What usually happens when WordPress announces PHP version bump is that hosting companies start to move WP sites to newer PHP versions. However that takes time. So these announcements should be made well ahead of the cut-off date.
3. After the above conditions are met, a final decision about the cut-off date can be made and be approved by the project leadership.

I also agree that this ticket is too early for 6.2 and should move to Future Release.

In that terms think this ticket should be milestoned to "future release", not 6.2.

Moving to Future Release but leaving 2nd-opinion keyword in place to invite more Core Committers to share their thoughts.

[azaozz]

Replying to JavierCasares:

Not sure this ticket is a good place for such discussion, but will try to answer your question hoping the answer will bring some clarifications.

But, are really those numbers real?

This is the global aggregated data the WordPress project has, here: ​https://wordpress.org/about/stats/ (click on "View as table"). Some (larger) hosting companies also probably have (or can get) similar data, and may choose to release it. May be interesting to see how that compares to the global data, but don't think it would influence a decision much.

If you have WP 3.9 + PHP 5.6, that's a ghost site… and this should'b be counted.

Yes, some sites that are on older WP versions are also running on older PHP versions. But other, (many more?) are on newer PHP too.

The "maximum 5% of sites that will be on unsupported PHP version" doesn't mean that the WP project will "leave 5% of its users behind". It means that (judging from previous experience) when that number is reached, chances are most of the remaining sites will be upgraded/moved to the minimum required PHP version by the cut-off date. Of course there will be some "unmovable" sites that are left behind. However the actual number of these unmovable sites on the cut-off date would probably be a lot less than 5%, more like under 1% as seen with previous PHP version bumps.

[SergeyBiryukov]

Replying to azaozz:

Per discussion with @azaozz, this means we can bump the minimum required PHP version

Yep, we talked about bumping it (about a month ago?) but don't think all the conditions are met yet.

Ah sorry, it looks like my understanding of these conditions was incorrect or incomplete :) I was excited to see 5.6 finally drop below 5%, should have checked with you first. Thanks for the clarifications!

1. The number of sites that will be "left behind" (on less than the new min version) have to be less than 5%, not 5% per PHP version. Currently that number is about 8.5% if excluding old WP sites that are on even older PHP versions.

That was indeed not quite clear to me, as previously noted in comment:143:ticket:33381. I think part of the confusion was that it does not seem to match what happened with the previous version bump.

The ​proposal post for bumping the minimum to PHP 5.6 mentions that for sites running WordPress 5.0, 85% were using PHP 5.6 or above at the time (9 Dec 2018). If we remove the version limit as suggested in the comments on #51043 and here, the usage of PHP < 5.6 across all WordPress sites on that date was almost 25%:

PHP 5.2	PHP 5.3	PHP 5.4	PHP 5.5	Total
2.30%	5.98%	10.20%	6.41%	24.90%

By the time the actual bump was committed in [45058] / #46594 (29 Mar 2019), the stats have changed a bit, though the usage of unsupported versions was still more than 20%:

PHP 5.2	PHP 5.3	PHP 5.4	PHP 5.5	Total
1.97%	4.96%	8.60%	4.97%	20.50%

That said, if the consensus is that the previous bump was premature, waiting until PHP < 7.2 (5.6, 7.0, and 7.1 combined) are less than 5% seems like the correct thing to do.

2. Even if the above number was at 5% or below, 6.2 is far too soon to bump the minimum PHP version. What usually happens when WordPress announces PHP version bump is that hosting companies start to move WP sites to newer PHP versions. However that takes time. So these announcements should be made well ahead of the cut-off date.

Looking at the previous post again, it was published in December with the proposed cut-off date in April. My thinking was that 6.2 would likely be released in April or May, which should give us a few months, same as last time. Based on this discussion though, it looks like more time is needed.

Either way, I appreciate the explanations, and it's great to have more clarity on the conditions. Thanks again!

[SergeyBiryukov]

Replying to SergeyBiryukov:

Looking at the previous post again, it was published in December with the proposed cut-off date in April. My thinking was that 6.2 would likely be released in April or May, which should give us a few months, same as last time.

Thinking about this some more, rather than waiting for three PHP versions combined to drop below 5%, and then waiting a few more months before the cut-off date, maybe we could do this in two steps for versions that are already below 5%?

• Announce dropping PHP 5.6 support in WP 6.2
• Announce dropping PHP 7.0 and 7.1 support in WP 6.3

[knutsp]

Replying to SergeyBiryukov:

• Announce dropping PHP 5.6 support in WP 6.2
• Announce dropping PHP 7.0 and 7.1 support in WP 6.3

I have always been in favor of doing this step by step (by PHP .x version), unless, of course, next two steps combined are smaller than the maximum 5% "left behind" (here 7.0 + 7.1). Announcing dropping PHP 5.6 in WP 6.2 will probably (force) migrate many of the 5.6 users to 7.4 or higher, paving the way for the next drop, and so forth.

By waiting, to be able to do several steps at once, we might end up waiting endlessly.

It is clearly time to drop PHP 5.6 support now, according to the earlier decided policy/strategy.

[snoringdragon]

To Replying to knutsp:

Replying to SergeyBiryukov:

• Announce dropping PHP 5.6 support in WP 6.2
• Announce dropping PHP 7.0 and 7.1 support in WP 6.3

I have always been in favor of doing this step by step (by PHP .x version), unless, of course, next two steps combined are smaller than the maximum 5% "left behind" (here 7.0 + 7.1). Announcing dropping PHP 5.6 in WP 6.2 will probably (force) migrate many of the 5.6 users to 7.4 or higher, paving the way for the next drop, and so forth.

By waiting, to be able to do several steps at once, we might end up waiting endlessly.

It is clearly time to drop PHP 5.6 support now, according to the earlier decided policy/strategy.

You are absolutely right.
If we didn't do it step by step as you mentioned, we will run into another blockage with php 7.4 like we did with php 5.6
That will also last for years.
Right now WordPress is still not fully compatible with php 8.0 even if it's been 2 years since it's release. What's more amusing is that security support for it is ending in nov 2023. So we will most likely reach it's EOL before WordPress is even fully compatible with it.
With this is mind, we have php 9.0 coming in less than 3 years.
More we delay thing, worse it will get at end.

[chris@…]

I'm 100% all for this, but I'm also curious what the general message for upgrading will be? PHP 7.x is EOL but PHP 8.x is still listed as "beta support" in the ​WP matrix?

We can tell people to upgrade to 7.x, but your average user is probably just going to pick the most recent version. I know 8.2 just came up, but if core still is "beta" for 8.0 and 8.1, I'm just not sure we're ready to force/encourage an upgrade yet.

And I know that most (or possibly all) of the "beta" is just deprecations, and "deprecations aren't errors", but your average user doesn't know that.

To be very clear, I really want this. I write in other frameworks, too, and it is really frustrating to switch between PHP versions, remembering what is supported in each version, so any upgrade of minimum version support will help with that.

[snoringdragon]

Replying to chris@…:

I'm 100% all for this, but I'm also curious what the general message for upgrading will be? PHP 7.x is EOL but PHP 8.x is still listed as "beta support" in the ​WP matrix?

We can tell people to upgrade to 7.x, but your average user is probably just going to pick the most recent version. I know 8.2 just came up, but if core still is "beta" for 8.0 and 8.1, I'm just not sure we're ready to force/encourage an upgrade yet.

And I know that most (or possibly all) of the "beta" is just deprecations, and "deprecations aren't errors", but your average user doesn't know that.

To be very clear, I really want this. I write in other frameworks, too, and it is really frustrating to switch between PHP versions, remembering what is supported in each version, so any upgrade of minimum version support will help with that.

Hi, there.

We will encourage users to upgrade to latest PHP version available for them at their hosting company.

There are few things to keep in mind.

1. If someone who is on PHP 5.6 is upgrading, they will most likely have to upgrade their plugins and themes too.
2. If some average user is upgrading PHP version, they will most likely seek hosting company's support, instead of doing it all alone.
3. With above two points in mind, it doesn't matter all that much if they upgrade to PHP 7.4 or PHP 8.0/8.1 as long as their plugins and theme are compatible with said PHP version.
4. We can also add an explanation at that ​PHP Compatibility and WordPress Versions post that beta support will work fine and users don't need worry about it as long as their plugins and theme are compatible with said PHP version.

Finally, we can show users running on PHP 5.6 a message about its support being dropped in WP 6.2 once they upgrade to WP6.2 and provide them link to a make blog post which explain how to upgrade to newer PHP version.

I hope this address your concerns.

[chris@…]

Finally, we can show users running on PHP 5.6 a message about its support being dropped in WP 6.2 once they upgrade to WP6.2 and provide them link to a make blog post which explain how to upgrade to newer PHP version.

Is support for PHP 5.6 being dropped in WP 6.2 or after 6.2? If they upgrade to 6.2 and 5.6 isn't supported, then they'd be broken? So we'd do it in 6.3 then? Or by "announcing" it, we're not declaring a specific version yet, just that it will be happening in a future version? I apologize, not trying to be pedantic, I just want to be clear.

I hope this address your concerns.

If there was an official current and stable (non-beta) version of WP that matched a non-EOL PHP, that would address it. It could be as simple as removing "beta" from the compatibility table.

I've read the note from ​two years ago about "beta compatibility", and I fully understand the difference between core's compatibility versus plugin and theme compatibility, along with the fact that many users will blame core if a plugin isn't compatible. But at a certain point I'd hope that we'd declare core itself at least fully compatible with some version of PHP 8, without any asterisks.

[azaozz]

Replying to SergeyBiryukov:

I was excited to see 5.6 finally drop below 5%

Same here :)

I think part of the confusion was that it does not seem to match what happened with the previous version bump.

The ​proposal post for bumping the minimum to PHP 5.6 mentions that

Gary's proposal was to bypass the "no more than 5% of sites on old versions" requirement, and also to give a bit less time until the bump. At the time the expectations were that many sites would be updated rapidly to PHP 5.6+. However that was proven wrong, and the proposal failed. Only a small part of the sites on older PHP versions were updated, and a large number (more than 10,000,000) were "left behind" (the numbers you posted also show this).

it's great to have more clarity on the conditions

I think the "no more than 5% of sites on old PHP versions" and "six months notice" were set with the previous bump to PHP 5.2/MySQL 5.0.

[snoringdragon]

Replying to chris@…:

Finally, we can show users running on PHP 5.6 a message about its support being dropped in WP 6.2 once they upgrade to WP6.2 and provide them link to a make blog post which explain how to upgrade to newer PHP version.

Is support for PHP 5.6 being dropped in WP 6.2 or after 6.2? If they upgrade to 6.2 and 5.6 isn't supported, then they'd be broken? So we'd do it in 6.3 then? Or by "announcing" it, we're not declaring a specific version yet, just that it will be happening in a future version? I apologize, not trying to be pedantic, I just want to be clear.

I hope this address your concerns.

If there was an official current and stable (non-beta) version of WP that matched a non-EOL PHP, that would address it. It could be as simple as removing "beta" from the compatibility table.

I've read the note from ​two years ago about "beta compatibility", and I fully understand the difference between core's compatibility versus plugin and theme compatibility, along with the fact that many users will blame core if a plugin isn't compatible. But at a certain point I'd hope that we'd declare core itself at least fully compatible with some version of PHP 8, without any asterisks.

Hi, sorry for confusion.
I meant WP 6.2 will be last WP version to support PHP 5.6 in case this ticket got accepted.
After that they will not be able to upgrade to next WP version unless they increase PHP version.
So no their sites will not be broken in any case.

WP team is actively working on deprecations introduced by PHP 8.0 and 8.1 once it is completed "beta support" label will be removed.

[snoringdragon]

Replying to SergeyBiryukov:

Replying to SergeyBiryukov:

Looking at the previous post again, it was published in December with the proposed cut-off date in April. My thinking was that 6.2 would likely be released in April or May, which should give us a few months, same as last time.

Thinking about this some more, rather than waiting for three PHP versions combined to drop below 5%, and then waiting a few more months before the cut-off date, maybe we could do this in two steps for versions that are already below 5%?

• Announce dropping PHP 5.6 support in WP 6.2
• Announce dropping PHP 7.0 and 7.1 support in WP 6.3

@azaozz can you share your take on this proposal?
Faster we iron it out, better it will be.

Sorry for ping

[azaozz]

Replying to SergeyBiryukov:

maybe we could do this in two steps for versions that are already below 5%?

• Announce dropping PHP 5.6 support in WP 6.2
• Announce dropping PHP 7.0 and 7.1 support in WP 6.3

Hmm, that may work but what would be the benefits for the WP users and contributors in bumping to PHP 7.0, and then again to 7.2 in few months? Frankly not seeing any significant ​new features in PHP 7.0 that would help the WP codebase much.

Bumping to 7.2 would (at least) mean a native Sodium lib and that we can drop the PHPUnit shims and start using PHPUnit 8.5 directly (as far as I see). Bumping to 7.4 would mean we can use PHPUnit 9.5 (latest) directly, etc.

Or perhaps can try to come up with a schedule that tries to predict when the number of sites would fall under 5% and pre-announces the bumps (look at trends, etc.)?

Still, imho, the best that can be done is to keep trying to convince the hosting companies to move WP sites to newer PHP versions. "Second best" would be to try to help the admins of sites on outdated PHP versions even more and to draw even more attention. Plugins like ​https://wordpress.org/plugins/php-compatibility-checker/ would still work afaik.

[azaozz]

Replying to snoringdragon:

can you share your take...

Yep, was typing when you posted this.

Sorry for ping

No problems :)

[jrf]

Replying to azaozz:

Bumping to 7.2 would (at least) mean a native Sodium lib

True, but the polyfill can not be dropped, even with a PHP 7.2 minimum as the extension is optional and PHP can even be compiled without it.

and that we can drop the PHPUnit shims and start using PHPUnit 8.5 directly (as far as I see).

Unfortunately, that is not true. There are still ​four Polyfills needed to be able to "write tests for PHPUnit 9.x and still be able to run them on PHPUnit 8.x".

Also, keep in mind that PHPUnit 10.x is expected soonish (current ETA Feb 2023) and will contain significant and extremely breaking changes. At this point in time it is unclear how long (limited) PHP cross-version support will be continued for PHPUnit 8.x/9.x, so chances are high that PHPUnit 10.x will need to be supported sooner rather than later.

[snoringdragon]

Replying to azaozz:

Replying to SergeyBiryukov:

maybe we could do this in two steps for versions that are already below 5%?

• Announce dropping PHP 5.6 support in WP 6.2
• Announce dropping PHP 7.0 and 7.1 support in WP 6.3

Hmm, that may work but what would be the benefits for the WP users and contributors in bumping to PHP 7.0, and then again to 7.2 in few months? Frankly not seeing any significant ​new features in PHP 7.0 that would help the WP codebase much.

Bumping to 7.2 would (at least) mean a native Sodium lib and that we can drop the PHPUnit shims and start using PHPUnit 8.5 directly (as far as I see). Bumping to 7.4 would mean we can use PHPUnit 9.5 (latest) directly, etc.

Or perhaps can try to come up with a schedule that tries to predict when the number of sites would fall under 5% and pre-announces the bumps (look at trends, etc.)?

Still, imho, the best that can be done is to keep trying to convince the hosting companies to move WP sites to newer PHP versions. "Second best" would be to try to help the admins of sites on outdated PHP versions even more and to draw even more attention. Plugins like ​https://wordpress.org/plugins/php-compatibility-checker/ would still work afaik.

Hi, it seems that you completely missed most important benefits which is standardization of minimum PHP version bumping process.

Even core committers are not sure about process prior to your clarifications which clearly demonstrates the issue.

If that is not good enough Indication of underlying issue, your current laid back behaviour further show the current WordPress situation.

You need to step up and follow standard procedure instead of trying to find reasons to avoid it.

Another benefit is that we can bump minimum PHP version in predictable manner instead of doing it when no other choice left.

1. We can drop PHP 5.6 support in WP 6.2 which will be coming in 2 or 3 months. In other words, users on PHP 5.6 will further drop by then.

2. Once we dropped PHP 5.6 support, users on it will move to new PHP version faster and it will also motivate people on PHP 7.0/7.1 to upgrade. We will most likely be able to drop their support in WP 6.3 which will be released in 9 months or so.

3. If that worked out fine, we can aim to further bump it to PHP 7.3 in WP 6.4 which will be available in 1.5 years.

4. Finally we can bump it to PHP 7.4 in WP 6.5/6.6 which will be released in next 2 to 3 years.

There is no shortcut to it.

I hope this makes you understand it's important.

[ZanderZ]

Replying to azaozz:
[...]

1. The number of sites that will be "left behind" (on less than the new min version) have to be less than 5%, not 5% per PHP version. [...]
2. [...] 6.2 is far too soon to bump the minimum PHP version. What usually happens when WordPress announces PHP version bump is that hosting companies start to move WP sites to newer PHP versions. [...]

Words cannot express how disappointing this statement is :( The last sentence highlighted in the quote should be a reason to make this announcement ASAP.
PHP 7.0.0 was released 7 years ago, that's ancient!

I really feel you should rethink the "5% total" rule, because as pointed out above, sites that are still on WP 5.1 or lower are likely ghost sites and shouldn't inhibit WordPress' progress.

[GaryJ]

Replying to azaozz:

Replying to SergeyBiryukov:

maybe we could do this in two steps for versions that are already below 5%?

• Announce dropping PHP 5.6 support in WP 6.2
• Announce dropping PHP 7.0 and 7.1 support in WP 6.3

Hmm, that may work but what would be the benefits for the WP users and contributors in bumping to PHP 7.0, and then again to 7.2 in few months?

I'd say that you answered your own question:

Still, imho, the best that can be done is to keep trying to convince the hosting companies to move WP sites to newer PHP versions.

As others have elaborated on as well, getting the train moving with that first bump to drop 5.6 would give incentive to the hosting companies to make the moves necessary (which in turn help users with performance and security, and contributors with new features, syntaxes and alignment with the rest of the PHP world), and not just to 7.0, especially if combined with:

Or perhaps can try to come up with a schedule that tries to predict when the number of sites would fall under 5% and pre-announces the bumps (look at trends, etc.)?

Makes sense. I believe that a roadmap of incremental bumps would actively help move the percentages in favourable directions, more than just the efforts related to the "keep trying" aspect of your statement. Holding back 95% of software consumers because of admirably wanting to support the 5% and being beholden to the hosting companies' business decisions doesn't seem to take ownership of the problem.

Frankly not seeing any significant ​new features in PHP 7.0 that would help the WP codebase much.

That isn't a reason not to make the move. Moving to PHP 7.0 minimum opens the door for the incremental move after that, and the one after that. It allows plugin and theme authors to have more confidence that they aren't leaving a proportion of their target audience behind for their PHP 7.x extension when core is still on 5.6.

7.0 introduces scalar and return types, and although WP core has generally been lax and uses type casting/conversions, it would allow a future where WP core was more strictly typed (at least for newly introduced code), which would reduce bugs in WP core and extensions.

I'd happily support Sergey's proposal - we've got to a point where a WP upgrade isn't an issue for users anymore with auto-updates, and I'd love to see the incremental approach so it means that minimum PHP bumps are a non-event for hosts and users and extension authors as well.

[azaozz]

Replying to snoringdragon:

Hi, it seems that you completely missed most important benefits which is standardization of minimum PHP version bumping process.

If by "standardization" you mean enforcing some written rules, I don't think it's needed. Deciding when to bump the minimum PHP and MySQL versions doesn't have to follow some (stifling) rules but is instead quite open. I've outlined above what has worked in the past and the decisions that were made about bumping minimum versions (as far as I remember).

You need to step up and follow standard procedure instead of trying to find reasons to avoid it.

Not sure what "standard procedure" is in this context. As with other infrequent tasks that affect a large number of users, each bump would ideally be proposed on ​https://make.wordpress.org/core/ and has to be approved by the project leadership, i.e. Matt or Josepha.

If it was possible, and was up to me, the minimum PHP version would have been 7.4 couple of years ago. However bear in mind that each bump comes at a cost. The cost is "users left behind" and it pretty high. When looking from this point of view:

• Total number of WordPress sites: 37m (most conservative number, counts WP networks as one site (afaik), comes from ​https://trends.builtwith.com/cms/WordPress).
• 5% requirement for bumping = 1,850,000 sites.
• Estimating half will be updated by the bump date, 925,000 sites remain.
• Estimating half of these are not maintained, 462,500 active sites are left behind.

Can you imagine standing in front of 462,500 people and telling them "Sorry, may not be your fault but no more updates for you". Eventually most of these sites will (slowly) be moved to newer PHP versions, but not all.

Imho to bump minimum versions and leave behind ~460k users the new version would have to bring some benefits for the remaining WP users. I don't see what benefits are there in bumping to PHP 7.0. Even bumping to 7.2 may not be particularly beneficial accosting to jrf's comment above.

1. We can drop PHP 5.6 support in WP 6.2 which will be coming in 2 or 3 months. In other words, users on PHP 5.6 will further drop by then.

2. Once we dropped PHP 5.6 support, users on it will move to new PHP version faster and it will also motivate people on PHP 7.0/7.1 to upgrade. We will most likely be able to drop their support in WP 6.3 which will be released in 9 months or so.

3. If that worked out fine, we can aim to further bump it to PHP 7.3 in WP 6.4 which will be available in 1.5 years.

4. Finally we can bump it to PHP 7.4 in WP 6.5/6.6 which will be released in next 2 to 3 years.

Yes, an estimated schedule (emphasis on "estimated") can probably be posted together with the next proposal to bump the minimum PHP version. Still, bumping the minimum version "just for the sake of bumping" (without any benefits for anybody) doesn't feel fair to the users that will be left behind.

[jrf]

Even bumping to 7.2 may not be particularly beneficial accosting to jrf's comment above.

Let me qualify that: in my opinion, bumping to PHP 7.2 will hugely benefit the project, just not for the reasons you mentioned.

[snoringdragon]

If by "standardization" you mean enforcing some written rules, I don't think it's needed. Deciding when to bump the minimum PHP and MySQL versions doesn't have to follow some (stifling) rules but is instead quite open. I've outlined above what has worked in the past and the decisions that were made about bumping minimum versions (as far as I remember).

No, it's NOT open. What you have outlined above is one sided decision taken by single person - Matt (Automattic). It's not a community led decision, so please stop acting like it is one.
Rules are needed to ensure things happen on time, be transparent and predictive.
Wordpress lacks basic decision making process. Why? Because Matt aka Automattic doesn't want one so as to have full control on WordPress.
So we need "rigid" rules for things to move ahead.

Can you imagine standing in front of 462,500 people and telling them "Sorry, may not be your fault but no more updates for you". Eventually most of these sites will (slowly) be moved to newer PHP versions, but not all.

Yes, I can. It IS partially their fault for not upgrading. When will that your "eventually" come? Like after next 2 years?
Also that number is not that big when you compare it to 37M (total users).

Imho to bump minimum versions and leave behind ~460k users the new version would have to bring some benefits for the remaining WP users. I don't see what benefits are there in bumping to PHP 7.0. Even bumping to 7.2 may not be particularly beneficial accosting to jrf's comment above.

@jrf has clearly mentioned that THERE are HUGE benefits to upgrading to 7.2
Since we can't upgrade directly to 7.2 because of some one sided outline, best possible first step is to bump to 7.0/7.1.

Sorry but I feel that it is useless to discuss anything here.
Like always, it's just going in circles.
To be fair, with azaozz blocking, there is no chance that it will ever merge.

[JavierCasares]

About the “standardization” / predictability, as we know, since PHP 7.0, PHP has launched a new version each end of the year (Nov / Dec). All the hostings are upgrading between Dec / Jan the new PHP versions, and deprecating the oldest ones, so, since PHP 7.0 (before it was not regular), yes, we have some predictability.

Some time ago, we discussed this in the Hosting team, and, it's not optimal, but try to get in the middle between Hosting companies, Security and developers. It's like an algorithm, so, it can be adapted. From the hosting Team we launched ​this page to have in mind everything about this.

Taking the actual versions:

WordPress / PHP / MySQL / MariaDB / Launch date
WordPress 6.1 / 7.4 – 8.1 / 5.7 – 8.0 / 10.3 – 10.9 / 2022-11-01

So, WordPress 6.1 should support PHP 8.1, PHP 8.0, and PHP 7.4 (security support) and, 3 more versions (2, 3? more years-versions). This makes support for PHP 7.3, PHP 7.2 and PHP 7.1.

If in March, we have WP 6.2, the calculation should be:

WordPress / PHP / MySQL / MariaDB / Launch date
WordPress 6.2 / 8.0 – 8.2 / 5.7 – 8.0? / 10.3 – 10.10? / 2023-03-nn?

So, WordPress 6.2 should support PHP 8.2, PHP 8.1, and PHP 8.0 (security support) and, 3 more versions (2, 3? more years-versions). This makes support for PHP 7.4, PHP 7.3, and PHP 7.2.

If we try and older version, the numbers should work the same:

WordPress / PHP / MySQL / MariaDB / Launch date
WordPress 5.1 / 7.1 – 7.3 / 5.6 – 8.0 / 10.1 – 10.3 / 2019-02-21

So, WordPress 5.1 should support PHP 8.0, PHP 7.4, and PHP 7.3 (security support) and, 3 more versions (2, 3? more years-versions). This makes support for PHP 7.2, PHP 7.1, and PHP 7.0.

Also, there were some remarks about having like some margin for major PHP versions, like when PHP 5 → PHP 7 happened, and like is happening with PHP 7 → PHP 8. In that case, the support for this “last version” should be extended like 1-2 years more because probably there are some breaking in the code, and also because there is unofficial support for those versions, like happened with PHP 5.6, and is happening with PHP 7.4.

And, after all this data, yes, I understand we may leave some people behind, but we should ask who is the responsible for this. Both user and hosting companies have responsibility. The hosting companies provide the tools to upgrade, and WordPress has their information dashboards about it, also Control Panels like cPanel or Plesk inform about this PHP deprecation, so, the information is there.

If people don't update their sites in a year, who is responsible? Only the user because the tools are there, the information is there, and also there is information for users and hosting companies on ​how to do an upgrade from older versions.

Moreover, now we have like 9 versions in core to support (PHP 5.6, 7.0, 7.1, 7.2, 7.3, 7.4, 8.0, 8.1, 8.2) creating some struggle for everybody (developers, hosting, test…) because the incompatibilities between a lot of these versions.

If somebody doesn't maintain their site in 5 years, with all the information is there, WE (as a Community) don't leave anybody behind, people are behind because they want because all the tools are in their hands. WE gave some time ago all the tools, the Site Health, the dashboard panels, the automatic updates, so, I understand the position from Matt, but don't think leaving some ghost sites behind is a problem.

[jason_the_adams]

As folks very fairly weigh the decision of bumping the minimum version in all its repercussions, I feel it's worth making a note regarding those "left behind".

If WordPress were a SaaS, or something like, breaking backwards compatibility would mean the software is broken — truly leaving folks in a bad place. It worked, and now it doesn't. Sorry.

WordPress, however, is distributed software. If a user has something (server specs, a plugin, etc.) preventing them from upgrading, then they're able to "safely" remain where they are. I say "safely" only to leave room for security updates, which don't actually apply here since security updates are applied to previous (to a point) versions of WordPress.

With this in mind, many (most?) plugins and themes support multiple versions of WordPress. GiveWP for example (where I work) supports back to 5.0 — as we have no reason not to. So, even if a user were to remain on an existing version of WordPress for a time, that doesn't necessarily even mean they can't update their plugins/themes. The plugins and themes themselves may choose to bump their minimum PHP version, of course, but many choose to do so now regardless of WP's official version.

All this to say, I think it's important to consider that "left behind" users are not immediately put into a disadvantaged position. They can remain where they are, receive security updates, and choose to overcome the PHP hurdle if and when they are ready. :)

[snoringdragon]

Hi,
Is there any possibility for it to be done in WP 6.3 cycle?

Today (11 February 2023), as per ​https://wordpress.org/about/stats/

PHP 5.6 is at 4.6% of all WordPress sites
PHP 7.0 is at 2.5%
PHP 7.1 is at 1.7%

Total => 8.8%

As of 17 Dec 2022

PHP 5.6 is at 4.99% of all WordPress sites
PHP 7.0 is at 2.68%
PHP 7.1 is at 1.82%

Total => 9.49%

These will decrease even further in next 6 months when WP 6.3 will be finally released.

(Edited to inclue stats of 17 December)

[costdev]

Looking at ​https://wordpress.org/about/stats on the Wayback Machine since January 2022, here's what it showed:

Month/Year	PHP 5.6	PHP 7.0	PHP 7.1	Total	Change since last
Jan 2022	7.1	4.0	2.9	14.0	Baseline. Continues through April 2022.
May 2022	6.0	3.3	2.3	11.6	-2.4% of all sites. -17.1% of PHP 5.6-7.1 sites. Continues through September 2022.
Oct 2022	5.1	2.7	1.8	9.6	-2% of all sites. -17.2% of PHP 5.6-7.1 sites. Continues through January 2023.
Feb 2023	4.6	2.5	1.7	8.8	-0.8% of all sites. -8% of PHP 5.6-7.1 sites.

Assuming the data shown on the page is accurate at the time (and using the best calculations available to me at the moment), this points to the transition slowing, so I don't think we're able to predict/suggest a milestone using the percentage of websites using PHP 5.6-7.1 at this time.

The general requirements for a bump are laid out in this comment, with an example notice of six months before a bump mentioned in this comment.

For now, IMO, I think it's best that we avoid acting on predictions of when a drop below 5% combined usage will occur, and instead either explore to what degree requirements are flexible (not at all, in some ways, etc), or wait until the combined usage is less than 5%, and resume discussion about possible next steps.

[ZanderZ]

WordPress 5.2 was the first version to require PHP 5.6. It was released in May 2019, so roughly 4 years ago. Sites that are currently on PHP 5.2-5.5 (2.1% of total) must still be using WP 5.2 or lower, because of this.
They are unlikely to upgrade to WP 6.3, so why are we still talking about "5% combined"?! Instead, let's focus on the 90% of sites that would benefit from a bump to PHP 7.0 (or higher) which will undoubtedly lead to better code in core (type declarations and return type declarations would be a HUGE benefit)

[snoringdragon]

Replying to costdev:

Looking at ​https://wordpress.org/about/stats on the Wayback Machine since January 2022, here's what it showed:

Month/Year	PHP 5.6	PHP 7.0	PHP 7.1	Total	Change since last
Jan 2022	7.1	4.0	2.9	14.0	Baseline. Continues through April 2022.
May 2022	6.0	3.3	2.3	11.6	-2.4% of all sites. -17.1% of PHP 5.6-7.1 sites. Continues through September 2022.
Oct 2022	5.1	2.7	1.8	9.6	-2% of all sites. -17.2% of PHP 5.6-7.1 sites. Continues through January 2023.
Feb 2023	4.6	2.5	1.7	8.8	-0.8% of all sites. -8% of PHP 5.6-7.1 sites.

Assuming the data shown on the page is accurate at the time (and using the best calculations available to me at the moment), this points to the transition slowing, so I don't think we're able to predict/suggest a milestone using the percentage of websites using PHP 5.6-7.1 at this time.

The general requirements for a bump are laid out in this comment, with an example notice of six months before a bump mentioned in this comment.

For now, IMO, I think it's best that we avoid acting on predictions of when a drop below 5% combined usage will occur, and instead either explore to what degree requirements are flexible (not at all, in some ways, etc), or wait until the combined usage is less than 5%, and resume discussion about possible next steps.

New PHP versions (minor or major) are released in Nov/Dec each year. We will have PHP 9.0 in Nov/Dec 2025. So, that will be around 2.5 years.

After reducing 6 months of advance notice, we need to drop support for PHP 5.6/7.0/7.1/7.2/7.3 (not talking about 7.4) in next 2 years unless we plan to introduce a lots of new polyfills.

We should preferably drop PHP 5.6, 7.0 and 7.1 support in a year, so wordpress devs are better prepared for handling PHP 9's arrival as its RFCs gets accepted.

BTW, Phpunit 10 was released on 3rd Feb 2023. It introduces breaking changes and requires PHP 8.1 or later.

I think we should aim to drop support for PHP 5.6 (not talking about 7.0 and 7.1) in WP 6.3 and release make post asap. We meet all conditions required to drop support for PHP 5.6
As for 7.0 and 7.1, we should aim to drop their support in WP 6.4/6.5

Thanks a lot for your time.

[Hareesh Pillai]

I second the opinion that we should drop support for PHP 5.6 in the upcoming major (since its usage has dropped below 5%), and then eventually figure out a timeline for further bumps.

[samiamnot]

Sadly there has been very little change in real world WordPress ​PHP versions over the past year. The total use of PHP < 7.2 only dropped 0.6% in over a year.

Month/Year	PHP 5.6	PHP 7.0	PHP 7.1	Total
Feb 2022	4.6	2.5	1.7	8.8
Mar 2023	4.3	2.3	1.6	8.29

[SergeyBiryukov]

Replying to samiamnot:

Sadly there has been very little change in real world WordPress ​PHP versions over the past year.

It looks like the numbers for Feb 2022 in your table come from comment:62, but the data there is actually for Feb 2023, it's just that the label was incorrect (updated now).

Here's the current data for April:

Month/Year	PHP 5.6	PHP 7.0	PHP 7.1	Total
Apr 2022	6.6	3.7	2.7	13.0
Apr 2023	4.4	2.3	1.6	8.3

So the total use of PHP < 7.2 actually dropped 4.7% over the last year.

[justlevine]

Confused why we're looking collectively at <7.2, instead of handling each PHP version separately. 5.6 should have been dropped as soon as the criteria were met.

+1 for rectifying this by removing 5.6 in v6.3, and then (unless their usage numbers go up) 7.0 and 7.1 in the subsequent release (when removing those releases meets the same criteria).

Going forward I think this step needs to be a standardized part of the release process - if the criteria are met, then that PHP version should be announced/slated for removal. Think the lack of consistency is a bigger issue than whatever the actual criteria for removal are (which seems to be what much of the discussion on this ticket focused around).

[spacedmonkey]

@SergeyBiryukov PHP 5.6 is less than 5%. Could we bump in the min requirement to 7.0? Then do 7.2 later?

[ZanderZ]

Adding my two cents again: WP 5.6 added "beta" support for PHP 8.0 (5.9 did for 8.1 and 6.1 did for 8.2). PHP 8 usage is now at 22.5%, over 5 times a much as PHP 5.6 usage (currently at 4.2%)!

Even if you combine all PHP 5 versions (which makes no sense because they can't update to the latest WP version anyway), they have only 5.9% usage. Please, stop supporting ancient PHP versions in favour of modern PHP! The core codebase could benefit so much from dropping 5.6...

[knutsp]

Replying to spacedmonkey:

@SergeyBiryukov PHP 5.6 is less than 5%. Could we bump in the min requirement to 7.0? Then do 7.2 later?

Yes, no need to wait. PHP 7.0 came with

• Significantly reduced memory usage
• The null coalescing operator (??) (avoids a lot of isset checks and conditions just to safely have a default value. In WP especially useful when accessing possibly non existent, non required array keys.
• Return and Scalar Type Declarations
• etc.

So we can start modernizing the code once a decision is made.

[samiamnot]

Updated ​stats.

Month/Year	PHP 5.6	PHP 7.0	PHP 7.1	Total
Apr 2022	6.6	3.7	2.7	13.0
Apr 2023	4.4	2.3	1.6	8.3
May 2023	4.19	2.21	1.51	7.91

[SergeyBiryukov]

Replying to spacedmonkey:

PHP 5.6 is less than 5%. Could we bump in the min requirement to 7.0? Then do 7.2 later?

Yeah, that's what I suggested in comment:34, but reading further discussion in comment:45 and comment:54, it's not quite clear to me whether that approach would have consensus from the leadership.

With PHP 5.6 + 7.0 + 7.1 currently at 7.91% and ​WP 6.3 planned for August, PHP < 7.2 may or may not drop below 5% by that time. Happy to propose dropping PHP 5.6 in WP 6.3, but the reply would still likely be same as in comment:54 :)

[samiamnot]

It may or not be relevant, but is there a way to get stats as to what WordPress version the PHP 5.6, 7.0 and 7.1 sites are on? If they are mostly on old unsupported WordPress versions they may indicate unmaintained sites. Will this make a difference? As a side-note, the total dropped to 7.89% (from 7.91%) last 3 days 😉.

[SergeyBiryukov]

Replying to samiamnot:

If they are mostly on old unsupported WordPress versions they may indicate unmaintained sites. Will this make a difference?

If I remember the discussion in #51043 correctly, counting only recent WordPress versions may indeed show a higher percentage of newer PHP versions, but that won't make a difference, we need PHP < 7.2 to drop below 5% across all WordPress versions.

[masteradhoc]

+1 on seperating the upgrading of the minimum php version for wordpress.

​Updated stats.

Month / Year	PHP 5.6	PHP 7.0	PHP 7.1	PHP 7.2
Apr 2022	6.6	3.7	2.7	?
Apr 2023	4.4	2.3	1.6	?
Mid May 2023	4.16	2.19	1.49	6.26

What i could see doable is:

WordPress Version	Minimum PHP Version	PHP EOL since Date*	Comment
WP 6.3	PHP 7.0	31 Dec 2018	PHP 5.6 Support will be dropped
WP 6.4	PHP 7.2	10 Jan 2019 1 Dec 2019	PHP 7.0 will be dropped PHP 7.1 Support will be dropped
WP 6.5	PHP 7.3	30 Nov 2020	PHP 7.2 Support will be dropped TBD as currently still on 6.26% - might be possible to get that number below 5% for that release

• ​EOL Date PHP

This will bring another good awareness of keeping things up to date for all people involved.

[JavierCasares]

What i could see doable is:

WordPress Version	Minimum PHP Version	PHP EOL since Date*	Comment
WP 6.3	PHP 7.0	31 Dec 2018	PHP 5.6 Support will be dropped
WP 6.4	PHP 7.2	10 Jan 2019 1 Dec 2019	PHP 7.0 will be dropped PHP 7.1 Support will be dropped
WP 6.5	PHP 7.3	30 Nov 2020	PHP 7.2 Support will be dropped TBD as currently still on 6.26% - might be possible to get that number below 5% for that release

​PHP 8.3 will be released on 2023-11-23, and the ​support-end for PHP 8.0 2023-11-26, so, closing the gap will be great.

PHP 7.4 will be difficult to reach because it is a well-established version. But having the goal to go from PHP 5.6 to PHP 7.4, as a minimum, is great.

[knutsp]

Replying to azaozz:

Replying to SergeyBiryukov:

maybe we could do this in two steps for versions that are already below 5%?

• Announce dropping PHP 5.6 support in WP 6.2
• Announce dropping PHP 7.0 and 7.1 support in WP 6.3

Hmm, that may work but what would be the benefits for the WP users and contributors in bumping to PHP 7.0, and then again to 7.2 in few months? Frankly not seeing any significant ​new features in PHP 7.0 that would help the WP codebase much.

I take it as the stats for the individual PHP versions to jump out of showing lower than 5% in no longer the obstacle to bump the minimum version. The jump also has to have benefits and significant new features (to help the codebase). This means maybe wanting to jump several versions ahead at once, like to 7.4, while the percentage using versions left behind piles up.

It seems like the is a burden to bump minimum PHP, so it must be enough to gain.

Each bump is a very powerful signal, both to users and hosting companies, to act. And, of course, the recommended version to upgrade to will not be 7.0, but 8.2 or at least 7.4. Then some burden is taken off the load for the next bump, like 7-8 months later. Since 7.0 + 7.1 is so minimal, next can be 7.2, then 7.4.

1. What is actually the burden, for core team, and other teams, of jumping minimum PHP?
2. As I pointed out in my #comment:72 the are a few very interesting new features, like null coalescing, and salar types for functions, that can start being implemented immeditaly, and at the same time, "forcing" PHP7 upon users, now, will (just) make their sites significantly faster and less memory consuming.

[Hareesh Pillai]

As much as I would like PHP 5.6 support dropped at the earliest, I doubt if it would be feasible to manage it in time for the WP 5.6 release (which is expected to go out in August '23, with code freeze still earlier)

I propose that we target WP 6.4 to drop support for PHP 5.6 (and preferably 7.0 and 7.1 as well). This will provide us ample time to put up the Make blog post and inform the developers, users etc.

[masteradhoc]

Replying to Hareesh Pillai:

I propose that we target WP 6.4 to drop support for PHP 5.6 (and preferably 7.0 and 7.1 as well). This will provide us ample time to put up the Make blog post and inform the developers, users etc.

Information is important and it definately should go out as early as possible. But…

Do you really think there are still much todos for plugin authors and theme authors? As those that still would need to do somthing are probably abandoned anyway. Most those have a userbase thats by far further than php 5.6.

I would still vote for seperate and a early communication of a planned schedule to raise again awareness of upcoming changes and also encouraging themes/plugins to update their codebase.

Let‘s just get started and do it step by step than rather pushing it out again and then still dont do in 6.4 for another reason..

[justlevine]

In order to increase the likelihood of this actually being this actionable this time around, would it make sense to create a new ticket specifically targeting dropping 5.6?

That way we can have a scoped discussion/decision about the when/how, and if leadership shoots it down then at least we finally have a clear (albeit unfortunate) answer as to whether we can do it separately or need to wait and drop it with 7.0/7.1.

(Asking bc I'm not familiar enough with Trac culture to know if this would actually be effective, or just cause the issue to fall off the radar again)

[johnbillion]

@SergeyBiryukov @azaozz I am in favour of changing this ticket to target PHP 7.0 instead of 7.2. What do you say?

As mentioned several times above, this might not gain us huge benefit in terms of the core code but it will move us further down the path. Incremental improvements are always going to be easier to justify and implement than larger ones.

PHP 5.6 is at 4.2% of installations, safely under the target 5% that's needed before we can consider dropping support.

[samiamnot]

My feeling is that doing this in steps will make things harder. Many will take the approach that there is less risk in moving from 5.6 to 7.0 instead of moving to a more modern version. We would just be delaying things (since it may require multiple updates over time). As it stands now, by the time 6.3 is delivered, we can likely make 7.2 the minimum. Maybe we should try a very in-your face warning in wp-admin in 6.2.2 release, warning anyone <= 8 that the PHP version that they are using is already EOL and they should upgrade to a newer version. This poses no risk and MAY get people to speed up their update.

[SergeyBiryukov]

Replying to johnbillion:

I am in favour of changing this ticket to target PHP 7.0 instead of 7.2. What do you say?

Let's try that :) With ​WP 6.3 planned for August 8, we have almost three months to announce the change. Would that be enough, or should we aim for 6.4?

[justlevine]

Replying to samiamnot:

My feeling is that doing this in steps will make things harder. Many will take the approach that there is less risk in moving from 5.6 to 7.0 instead of moving to a more modern version.

Anecdotally this is not my experience, if something in the stack (e.g. plugin or host) drops PHP supports, my clients want me to update to the _latest_ compatible version so they don't need to do it again for a while. I'm sure the hosting team or maybe plugin stats can confirm one way or the other.

[johnbillion]

My vote goes to 6.3. We've got almost three months and we're already within the self-imposed metrics for such a change. I've updated the ticket details accordingly.

For anyone reading along, this does not mean this will definitely happen in 6.3, just that it is being proposed. I will draft a make/core post and ask some other committers for input.

[samiamnot]

I am trying to understand the way WP considers things. The calculations for the minimum supported PHP version currently completely ignore versions no longer supported (such as PHP < 5.6). If we remove PHP 5.6 support in WP 6.3, that immediately paves the way to remove PHP 7.0 and 7.1 in WP 6.4 since those two versions already account for less than 5% (even currently and will certainly be lower down the road). By the time WP 6.5 is a few months from being ready, there is a good chance that PHP 7.2 that is now 6.26% will be < 5%. That basically is guaranteeing the following timelines:

• WP 6.3 will drop PHP 5.6
• WP 6.4 will drop PHP 7.0 and 7.1
• WP 6.5 will drop PHP 7.2

I am happy enough to go this rout, but it is funny math to me.

[samiamnot]

@johnbillion Sorry, I did not mean to revert your changes. I guess our messages were both being done at the same time.

[masteradhoc]

Replying to johnbillion:

My vote goes to 6.3. We've got almost three months and we're already within the self-imposed metrics for such a change. I've updated the ticket details accordingly.

Thanks @johnbillion ! I think the schedule from https://core.trac.wordpress.org/ticket/57345#comment:77 could be added to the post. Maybe 7.2 can be removed as we havent yet met the threshold. 👍🏻

[spacedmonkey]

For what my voice is worth, I am behind dropping support from PHP 5.6 in WP 6.3.

[azaozz]

Replying to johnbillion:

I am in favour of changing this ticket to target PHP 7.0 instead of 7.2.

Frankly I'm on the fence here. Don't really see any significant benefits that running WP on PHP 7.0 has over running on PHP 5.6. On the other hand chances are that the sites that are currently on 5.6 will be moved straight to 7.4 or even 8.0+. So at least these users may see some speed increase, etc.

My vote goes to 6.3. We've got almost three months...
For anyone reading along, this does not mean this will definitely happen in 6.3, just that it is being proposed.

Thinking three months may not be enough, but best would be to hear from the hosting community. As far as I'm aware each site would need to be tested separately with something like the ​PHP Compatibility Checker plugin, then moved and confirmed that is still works as expected. This is not a fast process :)

[spacedmonkey]

Frankly I'm on the fence here. Don't really see any significant benefits that PHP 7.0 has over PHP 5.6. On the other hand chances are that the sites that are currently on 5.6 will be moved straight to 7.4 or even 8.0+. So at least these users may see some speed increase, etc.

There is a speed benefit moving from PHP 5.6 to 7.0, not to mention security. There is along language improvements, like typing. But the biggest one for me, is tooling, as most modern php libraries do not support php 5.6, so we can not use them in our project. PHPUnit is a good example.

[eatingrules]

For what it's worth, Yoast SEO dropped support for <7.2 on April 11, 2023.

​https://developer.yoast.com/changelog/yoast-seo/20.5/#other

[johnbillion]

Don't really see any significant benefits that running WP on PHP 7.0 has over running on PHP 5.6.

Please, let's not drag this topic on any longer. The benefits of running a site on PHP 7 or 8 instead of PHP 5 are numerous, significant, and well documented, but that's not up for debate here.

The benefits of increasing the minimum supported version in WordPress core are ones that manifest over time and in multiple places, including within the plugin and theme ecosystem, within the long term outward perception of the WordPress project, within developer relations, and eventually within the WordPress codebase and its tooling. These are all topics that get discussed every time a PHP minimum version update are proposed, it's nothing new.

This is not a fast process :)

It doesn't have to be. Sites that are running PHP 5.6 on the day WordPress drops support for it will remain as-is and they can update both PHP and WordPress at their leisure. They're more likely to be under pressure from plugins and themes that have higher minimum PHP version requirements than core.

Trac ticket: https://core.trac.wordpress.org/ticket/57345

[joemcgill]

The ongoing opportunity cost that WordPress Core and the broader ecosystem incurs by continuing to support PHP 5.6, which has not received any updates since ​Jan 10, 2019 is not worth the benefit. We've historically set a 5% threshold for updating minimum versions. We've hit that threshold. We should loudly announce the intent to drop support for PHP 5.6 during this version as early as possible and change reporting of failures to unit tests for PHP 5.6 to warnings.

[titsmaker]

In my experience updating in small increments (e.g. from PHP 5.6 to PHP 7.0) makes sense as it puts less pressure on users. Most probably the number of problems introduced by such move would be limited and can be solved in reasonable time. Whereas skipping several increments of PHP can make your log a complete mess and turn updating codebase into something barely feasible, a nightmare. Thus updating to 7.0 would make sense even if there are no benefits to WP core. In general the approach to make small bump ASAP looks to me much more reasonable than to make some major bump but later.

[samiamnot]

Updated ​stats.

Month/Year	PHP 5.6	PHP 7.0	PHP 7.1	Total
Apr 2022	6.6	3.7	2.7	13.0
Apr 2023	4.4	2.3	1.6	8.3
May 2023	4.19	2.21	1.51	7.91
Jun 2023	4.06	2.13	1.44	7.63

Once 6.3 is live, do we stop looking at 5.6 just like we ignore numbers where PHP < 5.6? If we include 5.2 at 0.25%, 5.3 at 0.61%, 5.4 at 0.53%, 5.5 at 0.43% we would be unable to move to a PHP 7.0 minimum for a while since PHP versions 5.2 - 5.6 have a 5.88% market share. Assuming it is ignored, that opens us to easily set the minimum PHP version of 7.2 in WP 6.4, and we probably want to have that info published.

[masteradhoc]

@johnbillion any update on the make post? :)

[jorbin]

I have asked the hosting community to update ​https://github.com/WordPress/servehappy-resources/blob/master/tutorials/hosting-specific/tutorials-en.md which was linked to ​the last time the PHP version was updated.

​https://wordpress.slack.com/archives/C3D6T7F8Q/p1686229282520079

It looks like the following two instance have a requires_php value that also needs to be updated

I don't believe they do need updating because it's just mock data to ensure the health check works, but it doesn't hurt to change it so I'll get them updated anyway.

[spacedmonkey]

Related: #57067

[hlunter]

Replying to SergeyBiryukov:

Replying to samiamnot:

If they are mostly on old unsupported WordPress versions they may indicate unmaintained sites. Will this make a difference?

If I remember the discussion in #51043 correctly, counting only recent WordPress versions may indeed show a higher percentage of newer PHP versions, but that won't make a difference, we need PHP < 7.2 to drop below 5% across all WordPress versions.

I really don't get < 5% rule and I can't find any info on this. Why is this a criterion?

[johnbillion]

For transparency, this minimum supported PHP version bump is pending approval from Josepha or Matt. The make/core post will only get published when it's approved.

I really don't get < 5% rule and I can't find any info on this. Why is this a criterion?

You're right that this "rule" hasn't yet made its way into the core handbook. It's not concrete, it's one factor that's taken into account to determine if a minimum supported PHP version bump is warranted. Other factors include how long ago the prior bump was (2019 in the current case) and how fast the number is decreasing (0.1% every few weeks currently). 5% of WordPress sites is still hundreds of thousands of sites.

[JavierCasares]

The main thing is we don't have correlated data… We have WordPress version, PHP version, MySQL/MariaDB version, but we do not have WordPress + PHP version.

It is not the same WP 4.5 + PHP 5.6 as WP 6.3 + PHP 5.6.

Currently, we are not having in mind the “ghosts sites” because, if there is a 5.9% of sites with WP 4.5 + PHP 5.6, the limit can be increased because those sites will not be updated probably. The problem is with the newest sites.

Usually, if we do some magic, can see that “old WordPress versions” are related to “old PHP versions” in percentage.

If we may have that data, most likely the decision can be algorithmic and effortless because ​there is some info on how to update from old WordPress versions.

[masteradhoc]

@JavierCasares
Absolutely. But even if we can get the first bump to 7.0 it would be a good first step.
Still think this kind of a timeline should be

WordPress Version	Minimum PHP Version	PHP EOL since Date*	Comment
WP 6.3	PHP 7.0	31 Dec 2018	PHP 5.6 Support will be dropped
WP 6.4	PHP 7.2	10 Jan 2019 1 Dec 2019	PHP 7.0 will be dropped PHP 7.1 Support will be dropped
WP 6.5	PHP 7.3	30 Nov 2020	PHP 7.2 Support will be dropped TBD as currently still on 6.26% - might be possible to get that number below 5% for that release

• ​EOL Date PHP

@johnbillion When approx will we get a decision here? the 5% guideline was discussed for a long time and seemed the only blocker until now - hope that doesnt change.

[johnbillion]

There has been no response from Matt or Josepha and we're now in beta. Punting to 6.4.

[samiamnot]

Updated ​stats for Jul 2023.

Month/Year	PHP 5.6	PHP 7.0	PHP 7.1	Total
Apr 2022	6.6	3.7	2.7	13.0
Apr 2023	4.4	2.3	1.6	8.3
May 2023	4.19	2.21	1.51	7.91
Jun 2023	4.06	2.13	1.44	7.63
Jul 2023	3.94	2.06	1.39	7.39

in short, it is not moving quickly. I assume that the large hosting companies can probably do something about this is pushed.

[johnbillion]

After discussion with @chanthaboune this is going ahead for 6.3.

[samiamnot]

Replying to johnbillion:

After discussion with @chanthaboune this is going ahead for 6.3.

Given that WP 6.3 ends support for PHP 5.6, I assume that WP 6.4 will also end support for PHP 7.0 and 7.1 since they will at this point 7.0 and 7.1 total 3.43% of all WP sites supported by WP. It will be even lower by the time that 6.4 is ready for release. I asked this in #comment:101.

Based on ​stats for Jul 2023.

Month/Year	PHP7.0	PHP 7.1	Total
Jul 2023	2.05	1.38	3.43%

[johnbillion]

In 56141:

General: Increase the minimum supported version of PHP to 7.0.0.

This also removes the random compat library which is no longer necessary, and adjusts unit tests and CI workflows that no longer need to take PHP 5.6 into account.

Thank you for your service, PHP 5. Onwards!

Props SergeyBiryukov, mukesh27, dingo_d, audrasjb, jrf, costdev, azaozz, JavierCasares, hellofromTonya, samiamnot, spacedmonkey, masteradhoc, knutsp, garyjones, chanthaboune

Fixes #57345

https://core.trac.wordpress.org/changeset/56141

https://core.trac.wordpress.org/changeset/56141

[justlevine]

Guess this means now's the best time to start planning the next version bump ;-)
https://core.trac.wordpress.org/ticket/58719

[milana_cap]

This should be mentioned in the Field Guide, including the link to this post ​https://make.wordpress.org/core/2023/07/05/dropping-support-for-php-5/

[bjf2000]

Now that we've had a week of 6.3, has anyone been seeing this message around? I've seen a couple.

"Your server is running PHP version 5.6.40 but WordPress 6.3 requires at least 7.0.0."

I'm wondering how that happens (they're not my sites). I think the key question is this: does an automatic update in WordPress do any checking for requirements, like the new PHP v7 requirement in this case, before actually triggering the update or does it just barrel ahead? I would argue that being on the latest 6.2.x is far better than having a dead site, particularly since 6.3 wasn't even a security update.