PHP 8 support clarification

Welcome!

The WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:

Found a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.? Create a ticket in the bug tracker.

Want to contribute? Get started quickly with tickets marked as good first bugs for new contributors or join a bug scrub. There’s more on the reports page, like patches needing testing, and on feature projects page.

Other questions? Here is a detailed handbook for contributors, complete with tutorials.

tl;dr: Use of the “compatible with exceptions” label for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 8 support has been retired and has been retroactively removed from all versions. WordPress 6.3 and later is now documented as fully supporting PHP 8.0 and 8.1, and WordPress 6.6 and later is now documented as fully supporting PHP 8.2. Support for PHP 8.3 and 8.4 remains in betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. as of WordPress 6.7 and the upcoming 6.8.

WordPress has supported PHP 8 since version 5.6 back in 2020, but due to the acknowledgement that WordPress is rarely used in isolation (without any theme or plugins) this support has been labelled as “beta support”, and later as “compatible with exceptions” following the guidelines that were adopted as a result of the proposal for criteria for removing the “beta support” label from each PHP 8+ version.

In order to provide clarity and confidence to users and to encourage web hosts and users to continue updating to the latest versions of PHP, use of the “compatible with exceptions” label has now been retired. Documented support for any given version of PHP will now go straight from “beta support” to fully supported once the agreed criteria for removing that label have been met. The label has been removed retroactively from all versions.

PHP compatibility of all WordPress versions is documented here in the handbook and has been updated to reflect this change.

What prompted this change?

The criteria for removing the “beta support” label were adopted in 2023 just prior to the release of WordPress version 6.3. In that version a significant amount of work was done to resolve remaining PHP compatibility issues and to switch to using the “compatible with exceptions” label for PHP 8.0 and 8.1. The same was done in WordPress 6.6 for PHP 8.2, and the number and significance of these documented compatibility exceptions is now very low.

Since then it’s become apparent that some end users and web hosts remain reluctant to update to PHP 8 when the documented support in WordPress is still labelled as “compatible with exceptions”, despite the actual support being complete as far as most sites are concerned (over 60% of WordPress sites run PHP 8+). The label has served its purpose over the last 18 months but now risks being detrimental to the continued adoption of newer versions of PHP.

Removing this label — while still documenting the exceptions where necessary — will help continue the adoption of newer and fully supported versions of PHP and provide confidence to the remaining 40% of sites to update.

What are the criteria for removing the “beta support” label?

These criteria have not changed. The criteria are:

Enough sites: At least 10% of all WordPress sites running on a specific or newer PHP version for at least 3 months.
Issues:
- All reported and known compatibility issues are resolved.
- All accepted incompatibilities are documented as exceptions from full compatibility.
BC: Full backward compatibility is maintained for all older PHP versions WordPress supports, demonstrated with automated tests for each compatibility change.

Usage of PHP 8.3 and higher is at 8.9% of all WordPress sites as of April 2025. Once this surpasses 10% and assuming no further compatibility issues are reported then it’s expected that the beta label for PHP 8.3 support will be removed in the subsequent major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. of WordPress.

What’s the minimum supported version?

The minimum supported version of PHP remains unchanged at 7.2.24+.

Props to @desrosj @joemcgill @garyj for input on this change.

#php, #php-8-0, #php-compatibility

David Anderson / Team Updraft 9:20 pm on April 9, 2025

Tying the meaning of “betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.” to level of adoption in production means that in the WP world, the word has its own special meaning, one different to elsewhere.
As such, one could arbitrarily use any word(s). “This release has ‘chicken rodent’ status, where ‘chicken rodent’ means….. “
Sander 7:37 am on April 10, 2025

Since then it’s become apparent that some end users and web hosts remain reluctant to update to PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 8 when the documented support in WordPress is still labelled as “compatible with exceptions” […]

Usage of PHP 8.3 and higher is at 8.9% of all WordPress sites as of April 2025. Once this surpasses 10% and assuming no further compatibility issues are reported then it’s expected that the betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. label for PHP 8.3 support will be removed in the subsequent major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. of WordPress.

You’re still having a chicken and egg problem here. You’re saying web hosts/users are reluctant to upgrade, but then say the beta label is tied to how often it’s used. That will still keep people from updating their PHP version because they don’t want to run “beta software”.
Maxime Jobin 1:25 pm on April 10, 2025

First, I want to say this is a good news to change the way versions were labeled. There is a difference between “it is not compatible” meaning it will crash versus “it might not totally support all new features. I’m more interested to know if it will break a website versus will I be able to use all the new feature!

You’re still having a chicken and egg problem here. You’re saying web hosts/users are reluctant to upgrade, but then say the betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. label is tied to how often it’s used. That will still keep people from updating their PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher version because they don’t want to run “beta software”.

I have to agree with @zanderz (Sander) here. Could there be an alternative? Why updating WordPress’ code based on PHP release notes wouldn’t be enough to claim it is compatible and then adjust once launched? Maybe the beta and RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). cycles are just too tight to have enough time for testers to do what should be done!?

As we all know, all software come with incompatibilities and bugs. So no matter the effort, there will be problems. What I want to know is : are there known problems that will make the version update break my website?

Again, that is good news! So thanks for that!
- John Blackbourn 7:12 pm on April 10, 2025
  
  @maximejobin @zanderz I’m not particularly keen on the term “betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. compatible” either, but changing that was outside the scope of this change. I will see if there is any interest in changing that labelling during the 6.9 release cycle.
  - David Marín Carreño 9:02 am on April 16, 2025
    
    I think that it would be better to say if a given PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher version is supported or not.
    
    A supported PHP version would mean that it has been tested and there are not any known problems happening or warnings generated when running WP on it, and if users should expect that any problem that may appear when running WP on that PHP version will be fixed ASAP.
    
    This is GPLGPL GNU General Public License. Also see copyright license. software, so we shouldn’t expect any warranties. It would be more than OK to know, at least, if the effort to make adaptations to a given PHP version have been completed and users shouldn’t expect sites down, or clogged warning logs, when upgrading.

Welcome!

Communication

What prompted this change?

What are the criteria for removing the “beta support” label?

What’s the minimum supported version?

Share this:

Site resources