Tag Archives: php-compatibility

annezazu 7:56 pm on September 3, 2026
Tags: , php-compatibility, ,   

WordCamp US 2026: PHP conversation

At WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. US 2026, a group of contributors gathered for an informal conversation about the relationship between the WordPress project and the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher language and community. The discussion was held under the Chatham House Rule, so notes below are not attributed to individual participants.

Attendees: @jorbin @johnbillion @obenland @griffbrad @joemcgill @dmsnell @jason_the_adams @desrosj @mdawaffe @4thhubbard @westonruter @annezazu.

A framing question opened the conversation: what are our current pain points with the language, historically and today?

Pain points and concerns

Perception and Community Relations

  • Many in the PHP community don’t consider WordPress developers to be “PHP developers.” Part of this is due to WordPress being seen as dragging PHP backwards because of its backwards compatibility commitments.
  • Many PHP language features are discussed on the internals mailing list without a WordPress perspective in the room. This is something anyone can join but that we haven’t necessarily prioritized and causes missed opportunities. 
  • When folks raised a WASM proposal, there wasn’t interest at the time. It might be a more apt time to revisit this conversation.

Backwards compatibility and the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. ecosystem

WordPress’s long backwards compatibility window creates friction across the ecosystem:

  • Plugins that depend on other packages run into trouble because the broader PHP ecosystem doesn’t support versions as far back as WordPress does.
  • Possible responses discussed: contacting plugin authors directly, delisting incompatible plugins, and leaning on plugin developers to be more proactive. A complicating factor: most plugin authors aren’t keeping plugins up to date, and many don’t log in at all.
  • One forward-looking, wishlist idea that doesn’t solve backwards compat but that could potentially help with plugin security: PHP could add a language feature to load modules with flags applied, enabling a security policy for plugins. Any code required by untrusted code would itself be tainted as untrusted.

Testing and tooling

  • It can be hard to produce verifiable cases to test compatibility.
  • There’s an upcoming (not yet ready) release of PHP_CodeSniffer that fixes a lot of what we don’t currently have sniffssniff A module for PHP Code Sniffer that analyzes code for a specific problem. Multiple stiffs are combined to create a PHPCS standard. The term is named because it detects code smells, similar to how a dog would "sniff" out food. for. This would help extenders come up to standard quickly.
  • Code is landing in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ that isn’t compatible with PHP 7.4. Differences between the automated tooling for Gutenberg versus CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. cause issues when that code flows into Core. 
  • A nightly PHP Docker container to run locally would help. WordPress could put in the work to do it. Early follow has started here.

PHP version adoption

PHP 7.4 is still running on roughly 18% of websites (stats). There’s been less of a compelling reason for sites to upgrade recently. Ideas discussed:

  • A coordinated push from hosts to get more sites upgraded.
  • Making PHP 8.x meaningfully faster for WordPress, so speed becomes the compelling reason to upgrade. 
  • Security is already a reason to push on to update since older PHP versions that WordPress supports are no longer receiving security patches. 
  • The issue is not that folks are on old versions of WordPress itself. Stats could be pulled to see whether that has changed.

WASM

The last time a WASM proposal was raised it failed to gather enough interest for people to advance it into an RFC.  At the same time, PHP receives lots of security issues, and reducing surface area could be helpful to them. WordPress is already using WASM client-side and with Playground. A more meaningful conversation with the PHP community about WASM would be worthwhile. Tied to this, it may be worth running a PHP extension with WASM, gathering operational data and experience, and sharing that back with the PHP internals to show real world use. 

Context for historical involvement

We discussed why more involvement hasn’t happened without any one structural issue to point to. The main venues are PHP Internals and PHP-FIG. WordPress discussed joining FIG roughly 12 years ago but decided it didn’t want to be involved and wouldn’t get any benefit.

There have long been backchannel relationships and occasional public collaboration, but nothing intentional. Some context on why involvement has been limited:

  • WordPress doesn’t need much from the language and has always been conservative in adopting language features. Server performance and security are what pull WordPress in; language features are pushed harder by frameworks like Laravel.
  • This kind of collaboration is a constant uphill battle: highly technical, intense work requiring focus, time, and persistence across many people, and even when it makes something better for WordPress, it may still take ten years for WordPress to be able to take advantage of them due to the long-tail support for older PHP versions.
  • There’s an inherent mindset shift between software developers and language developers (examples raised: translations, time/date handling).
  • There is a reported history of patches stalling upstream.

Language features, version gating, and polyfills

A provocation was shared for this discussion: Could WordPress start gating features by PHP version aka “if you want feature X, you must run PHP X”? . Generally, WordPress uses polyfills to fill gaps, and there was discussion of collaborating with PHP on early polyfills:

  • When PHP 7 features were polyfilled early in a dedicated file, WordPress could implement features on top of that APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. faster.
  • It was discussed that polyfilling new functionality could disincentivize people to update their PHP versions. It was discussed that this argument may not hold: that instead of doing what it claims, it only causes breakage for sites with older PHP veresions and the incentivization loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop is broken.
  • The absence of polyfills led to the creation of multiple incorrect implementations in Core. Having polyfils would be a way of giving proper tools to prevent ad-hoc, insecure, and incomplete implementations in WordPress.
  • WordPress requires only a small number of PHP extensions (currently just jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. and mysqlMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com). Per the data from sites phoning home, PCRE is present on 100% of WordPress sites and could be made required.
    • The required/suggested page is out of date in a few ways and needs updating.

Incentives for hosts to update

Attendees who work at or with hosts shared what would motivate PHP upgrades:

  • Higher asset utilization. “Run 40% more websites on the same RAM,” with fewer people needed to monitor server security.
  • Security and performance generally, framed as “save by updating.”
  • Data from Automattic’s servers could show noticeable differences between PHP versions. There used to be PHP benchmarking across versions; WordPress.comWordPress.com An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://wordpress.com/ is already on PHP 8.4.
  • New PHP features might enable new technologies, such as AI-focused capabilitiescapability A capability is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability)..
  • MySQL has the same dynamic: new capabilities (vector search, for example) are being built while WordPress still supports very old versions.

Plugin developers

A release email could be sent to plugin developers when their plugins aren’t compatible with a PHP version.

Opportunities for overlap with PHP Core

  • Performance. There are Core PHP devs that have done substantial performance work in the text processing and other low-level functions space, and the last few PHP releases have all included heavy optimizations. WordPress sees benefits in the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. API but can’t take full advantage the way it could if that work were upstreamed. 
  • Upstreaming spec-compliant web standards into PHP: HTML parsing, URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org parsing, HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. parsing, Query arg parsing, MIME content-type inference. This is an area WordPress could help improve or sponsor work on, which would benefit WordPress and PHP at large.
  • WASM (see above).
  • Pushing hosts to update PHP (see above).
  • Do more to report back to the PHP internals and RFCs what our measured impacts are for different changes. Potential namespace resolution changes in PHP came up as an example as that would have real world impact on Gutenberg and new AI work (ex: the PHP AI Client).

Staffing around PHP compatibility

Staffing currently feels solid. Some history and risks:

  • There were rough patches, notably the PHP 8.0 update; 8.x releases have been more inclined to introduce breaking changes than past versions.
  • The bigger struggle is getting non-Core people (especially plugin developers) to be proactive about PHP compatibility.
  • WordPress makes local environments available to run tests against new PHP versions as soon as possible, and 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.” support label for new PHP versions was dropped.
  • PHP 9 might be a bigger issue. If a major syntax change in PHP 9 makes it impossible to ship a WordPress release supporting both PHP 7.4 and 9, mitigations discussed: asking PHP to produce nightly builds (playground lets you run WordPress on upcoming PHP versions), running WordPress Docker images against PHP nightlies, and taking unit tests out of the Docker container for more flexibility.

Potential follow-ups

  • Have a more intentional conversation with the PHP community about WASM.
  • Pull WordPress version stats to check whether old-WP-version distribution has changed.
  • Explore benchmarking data to give hosts a compelling upgrade story and to do an upgrade push.
  • Explore upstreaming HTML API work into PHP/find ways to sponsor PHP core development on behalf of WordPress.
  • Explore compatibility emails to plugin developers.
  • Follow the PHP_CodeSniffer release that adds missing sniffs, and the namespace resolution discussion.

Props to @dmsnell and @zieladam for reviewing these notes.

#php, #php-compatibility, #summary, #wcus

John Blackbourn 6:39 pm on May 22, 2026
Tags: , , php-compatibility   

PHP support clarification, spring 2026 edition

tl;dr: Use of 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 PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher support has been retired and has been retroactively removed from all versions.

  • WordPress 6.9 and 7.0 are now documented as fully supporting PHP 8.5
  • WordPress 6.8 and later are now documented as fully supporting PHP 8.4
  • WordPress 6.4 and later are now documented as fully supporting PHP 8.3

Due to the acknowledgement that WordPress is rarely used in isolation (without any theme or plugins), support for each version of PHP 8 has up until now been labelled as “beta” until its usage surpasses 10% on any given version of WordPress.

Since version 8.0, the PHP team has regularly shipped stable updates in the 8.x series. This means the work required to make plugins and themes compatible with the newer versions is much lower, and as such use of the “beta” label has been retired. The label has been removed retroactively from all versions. This will provide clarity and confidence to users, and encourages web hosts, developers, and users to continue updating to the latest versions of PHP.

Refer to the handbook page for documentation on PHP compatibility and WordPress versions.

What prompted this change?

The criteria for removing the “beta support” label from any given version of WordPress were adopted in 2023 after remaining PHP compatibility issues were resolved. Use of the “compatible with exceptions” label was retired in April last year and the number and significance of reported compatibility exceptions remains extremely low.

Additionally it’s become apparent that the “beta” label has made some end users and web hosts reluctant to update to newer versions of PHP, and caused some developers of plugins and themes to delay testing and supporting newer versions of PHP.

This label has served its purpose over the years, but can now be retired in order to continue increasing the adoption of newer versions of PHP throughout the ecosystem.

What’s the minimum supported PHP version?

The minimum recommended PHP version remains at 8.3. The minimum supported PHP version is 7.4 since WordPress 7.0. See the Requirements page for all the info.

How and why should I update PHP?

Keeping PHP up to date on your web server ensures your websites remain as performant and secure as possible. Read the guide to updating PHP.

Props to @garyj @westonruter and @jorbin for pre-publishing feedback.

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

John Blackbourn 3:38 pm on November 21, 2025
Tags: , , , php-compatibility   

PHP 8.5 support in WordPress 6.9

PHP 8.5 was released on November 20th. Contributors to WordPress have been busy in recent months preparing for this version and we’re happy to report that all issues reported against PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 8.5 have been addressed in WordPress 6.9 RC2. Compared to previous PHP releases relatively few changes were required, mostly to address new deprecations and warnings. Take a look at the PHP 8.5 support tracking ticket if you’re interested.

Due to the acknowledgement that WordPress is rarely used in isolation (without any theme or plugins), support is labelled as “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. support” until at least 10% of all WordPress sites are running that version or later, as this indicates good compatibility across the wider ecosystem of plugins and themes.

PHP Compatibility and WordPress Versions page in the WordPress Core Handbook

Following the established guidelines, support for any given version of PHP is labelled as “beta support” until at least 10% of all WordPress sites are running that version or later. When WordPress 6.9 ships on December 2nd, support for PHP 8.5 and 8.4 will be labelled as “beta support”. PHP versions 8.3 back to 7.2 are fully supported.

If you discover 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. or compatibility issue while running WordPress with PHP 8.5, please create a ticket on Trac.

Summary

As always, reading through the complete upgrade document is recommended.

Even as WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. continues to expand its support for new versions of PHP, support for older versions will remain as-is in WordPress 6.9, staying at PHP 7.2.24 and higher. This will continue to be evaluated and no change will be made until usage numbers show that the impact on users will be minimal.

WordPress continues to encourage all users to run the latest and greatest versions of PHP, including PHP 8.5.

Props @desrosj, @jorbin for reviewing this post.

#6-9, #dev-notes, #dev-notes-6-9, #php-compatibility

John Blackbourn 10:19 am on July 7, 2025
Tags: , , php-compatibility   

Proposal: Remove the “beta support” label from PHP 8.3 for WordPress 6.8

Update: This change has been agreed and implemented.

WordPress 6.4 to 6.8 are labelled as having “beta support” for PHP 8.3. The coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. software itself is compatible and has been since November 2023, but due to the acknowledgement that WordPress is rarely used in isolation (without any theme or plugins) this support is labelled as “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. support”.

Last month, combined usage of PHP 8.3 and higher surpassed 10% of all WordPress websites. I am proposing two small adjustments to the criteria for removing the “beta support” label from each PHP version:

  1. Remove the “for at least 3 months” clause from the “Enough sites” indicator. 10% of all WordPress sites is somewhere well north of 3 million and the 3 month clause seems unnecessary at that scale.
  2. Allow the label to be retroactively removed from the current 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.. There is no need to wait for the next major release to update the support status if its only remaining criteria is based on usage numbers.

With these two small adjustments, the “beta support” label for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 8.3 can be removed from WordPress 6.8. If there are no objections then I’ll make this change this week.

What does this change mean for users and extenders?

Declaring PHP 8.3 as fully supported will help continue to provide clarity and confidence to users and to encourage web hosts and users to continue updating to newer versions of PHP. Users and extenders of WordPress can be confident using and recommending more up to date versions of PHP when the WordPress project continues to test, support, track, and encourage use of newer versions both in the core software and throughout the ecosystem.

What about PHP 8.4?

PHP 8.4 was released in November 2024 and its usage is currently at 1.5%, therefore its “beta support” status will remain in place for now.

What about PHP 8.5?

Hold your horses, PHP 8.5 is still in development and its release is planned for November 2025.

Thanks to @jorbin for proof-reading and suggestions prior to publishing.

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

John Blackbourn 9:14 am on April 9, 2025
Tags: , , php-compatibility   

PHP 8 support clarification

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
  • WordPress 6.6 and later is now documented as fully supporting PHP 8.2
  • WordPress 6.8 and later is now documented as fully supporting PHP 8.3
  • Support for PHP 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.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

Tonya Mork 3:40 pm on June 20, 2023
Tags: , , php-compatibility   

Proposal: Criteria for Removing “Beta Support” from Each PHP 8+ Version

Update on August 1, 2023: Added requirement to publish Make/CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. post that details the compatibility change for the release (added to the “Beta Support” removal process section). Props @chanthaboune.

Update on April 9, 2025: Use of the “compatible with exceptions” label has been retired. Full info here.

Update on July 8, 2025: The “Enough sites” criteria has been adjusted. The three-month incubation period has been dropped, and 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 can be removed from the current major version retrospectively. Full info here.

Officially WordPress Core currently provides “beta support” (or “beta compatibility”) for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 8.0, 8.1, and 8.2, as per the compatibility table in the handbook. The term “beta support” was first used in 2020 for WordPress 5.6 and PHP 8.0, though no criteria were set for determining when it could be removed. When should WordPress Core be considered compatible with a specific PHP version? Could it be compatible even with known and documented incompatible exceptions? This proposal is being set forth by a group of trusted contributors (see the props list below) who have consistently focused on the overall forward and backward compatibility of WordPress in the context of PHP as a way to outline any criteria, data, or roadmap needed to answer these questions.

The scope and goals of this proposal are:

  • Set the criteria for determining when WordPress Core has reached compatibility with a specific PHP version that WordPress supports.
  • Once the criteria are met, then the “beta support” classification can be removed for that WordPress version and beyond.
  • Set a phased approach for moving from “beta support” → to compatible with exceptions (optional) → to fully compatible.

The proposal starts with an understanding of what “compatibility” means, then dissects the meaning to identify indicators, and finally uses the indicators to build decision-making criteria.

What is outside the scope of this proposal?

  • Theme or pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. compatibility. There is no guarantee that any theme or plugin a site owner uses is compatible with or safe to upgrade to a PHP version. Rather, this proposal is for WordPress Core itself.
  • List of supported PHP versions. It is not for determining which PHP versions WordPress should support, e.g. PHP EOL (End of Life), raising the minimum supported PHP version, etc.

Quick navigation

  1. What compatibility means
  2. Identifying indicators
  3. Proposed compatibility criteria
  4. “Beta Support” removal process
  5. Conclusion

1. What compatibility means

Because of the nature of WordPress usage and the commitment to our user base, compatibility is to be considered in the eyes of those users. The goal is to elevate the broader ecosystem to a state that is compatible with PHP 8. That requires that the Core software not just be compatible on its own, but also provides defenses against common problems seen in the transition to PHP 8, while continuing to function on older versions of PHP.

~ What does compatibility mean here? from WordPress and PHP 8.0 by @desrosj

Building upon the above quote, compatibility means:

WordPress Core’s compatibility with a specific PHP version happens when enough sites run without issues (a) in the ways users configure and use their sites (b) while also continuing to function on all older PHP versions WordPress supports.

Notice this description intentionally focuses on users with emphasis on the ways users use WordPress. WordPress is committed to being user-first. Technical decisions (including compatibility) should first focus on users and thus usage.

Is full 100% compatibility required before removing “beta support”?

No. This proposal does not require a full 100% compatibility requirement for removing “beta support”. Instead, it takes a more pragmatic phased approach.

Some PHP version features or changes are breaking changes that (a) may require more effort and time to fully resolve or (b) may not be fully resolvable due to various reasons such as external dependencies, backward compatibility, etc.

Imagine the scenario where the bulk of WordPress Core is compatible with a specific PHP version but there are one or more incompatibilities yet to be resolved. Should those incompatibilities blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. removing “beta support”? Or could those be accepted and documented as exceptions?

This proposal proposes the following phases:

  • “beta support”
  • compatible with documented exceptions
  • full compatibility

Reaching full 100% compatibility may not always be possible or it may take extensive amount of time. This should not block the removal of the “beta support” label. If one version is blocked, then all versions after that version are also blocked. By taking a phased approach, the project retains flexibility to take decisions that are best for users and the broader ecosystem.

2. Identifying indicators

In dissecting the above meaning, the keys to achieve compatibility reside in:

  • Enough sites: enough sites running on a given PHP version over enough time.
  • Issues: all known compatibility issues resolved or accepted as incompatible.
  • BC: compatibility changes are backward compatible with all earlier PHP versions WordPress supports.

Enough sites: What does a minimum threshold of sites signify?

Enough sites should indicate a variety of different usages. Usages are important.

It can indicate WordPress itself runs with different technical stacks of themes, plugins, configurations, and hosted environments.

WordPress is never used in isolation (without any theme or plugins), so WordPress itself being able to run on PHP 8 does not indicate “full” compatibility…

The state of PHP 8 support within the broader ecosystem (plugins, themes, etc.) is impossible to know.

~ WordPress and PHP 8.0 by @desrosj

Usages can also indicate a variety of the WordPress functionality is being used by users. Why is this important? It can indicate how much of the WordPress Core’s source code is being run on a specific PHP version with the different technical stacks.

Issues: What does “issues” signify?

If the number of sites running on a specific PHP version continues to grow over time, then an inference could be made that the sites run without issue. How so? The thinking is: why would the usage grow over time if there are compatibility issues blocking sites from running on the version? Using that logic, the growth of “enough sites” over time can indicate there are no known compatibility “issues”.

Historically, WordPress relies on users to provide feedback and report issues. Thus, the “issues” indicator also means all known compatibility issues are resolved or excluded. (Note: In TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., the phpNN keyword convention (e.g. php80, php81, and php82) identifies a PHP compatibility issue or task. A new php-compatibility focus is also proposed for further help with identifying compatibility tickets.)

Thus, “issues” can be considered as a combination of the growth of enough sites over time and all reported and known compatibility issues are resolved or accepted as incompatible.

What is resolved?

A known issue is resolved by various actions including fixed, closed, accepted as not impacting compatibility, or documenting as being incompatible.

Backward compatibility: How does backward compatibility relate to PHP versions?

Users and user confidence. WordPress has a long history of prioritizing backward compatibility (also known as BC and back compatback compat Backward compatibility - a desire to ensure that plugins and themes do not break under new releases - is a driving philosophy of WordPress. While it is a commonly accepted software development practice to break compatibility in major releases, WordPress strives to avoid this at all costs. Any backward incompatible change is carefully considered by the entire core development team and announced, with affected plugins often contacted. It should be noted that external libraries, such as jQuery, do have backward incompatible changes between major releases, which is often going to be a greater concern for developers.) to ensure WordPress runs for users regardless of which PHP version they are using. In this way, users can upgrade to a newer PHP version with the confidence their site will continue to function.

PHP 8 introduces many breaking changes, meaning the changes in the language do not work on versions older than PHP 8. To make WordPress compatible with PHP 8, changes must also stay compatible with all PHP versions it supports.

How can backward compatibility be determined?

Each change must not change the previously intended behavior or code usage (e.g. function names or signatures, input types or data structures, return types or data structures, etc.) and must work on all WordPress supported PHP versions.

The adopted approach is to add automated tests prior to the compatibility change and then ensure the change does not alter the behavior or code usage.

3. Proposed compatibility criteria

Using the above indicators, let’s build criteria for determining when a WordPress version is compatible with a specific PHP version.

All of these indicators must be true for a specific PHP version:

  • Enough sites: At least 10% (i.e. usage percentage) of all WordPress sites running on a specific or newer PHP version for at least 3 months.
    • The usage percentage is calculated by combining usages of the target version plus all newer versions. For example, the PHP 8.0 % of usage is the sum of usage from 8.0, 8.1, 8.2, etc.
  • 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.

The criteria in action for WordPress 6.3

Let’s see the proposed compatibility criteria in action. Could the “beta support” label be removed in WordPress 6.3 for different PHP 8 versions?

As of June 19, 2023:

  • Enough sites:
    • PHP 8.0: 13.49% (+8.92% from PHP 8.1 +1.41% from PHP 8.2 = 23.82% ✅ )
    • PHP 8.1: 8.92% (+1.41% from PHP 8.2 = 10.33% ✅ )
    • PHP 8.2: 1.41%
  • Issues:
    • Current list of reported issues:
    • Possible Incompatibilities for acceptance consideration:
      • Named parameters: Should WordPress be fully-compatible with named parameters? There are backward compatibility (BC) considerations to consider. Once WordPress is compatible with a specific PHP version, the names of function/method parameters can never change as any changes would be a BC break (See Trac 57838).
      • Explicitly setting default value of the flags parameter for htmlentities() et all (See Trac 53465).
  • BC: there are no known unresolved backward compatibility issues, though there is not a specific keyword available for tracking.

PHP 8.0 and 8.1 meet the minimum “enough sites” criteria, but have open tickets that need to be resolved to pass the “issues” criteria. Once each is resolved or accepted as incompatible, then it is possible for WordPress 6.3 to be declared compatible (possibly with incompatibility exceptions) with PHP 8.0 and 8.1.

Why not use the automated test suites as the compatibility indicator?

Automated tests are an important part of the testing and feedback loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop strategy in software development. A good set of tests can identify problems before the code ships to users.

But as previously noted, users are not running WordPress by itself, but rather as part of a stack of technologies. Knowing the majority of possible usage scenarios (such as an array of different themes and plugins) to use as test data is difficult. Thus, automated testing is part of an overall strategy when combined with the other indicators previously noted.

The automated tests are not included as part of the indicators. Currently the WordPress automated test suites are not yet significant or good enough to indicate with confidence that the source code is fully compatible and meets all of the above criteria.

What is required for the test suites to be considered significant and good enough?

  • The vast majority of the code would need to be exercised by the tests.
  • A broad set of scenarios for what should (happy path) and shouldn’t (unhappy path) happen in the ways users configure and use WordPress.

Currently, the WordPress Core’s automated test suites do not meet this criteria. For example, using the published code coverage report, less than half of the code is being exercised by tests. (Note: the published code coverage report is misleading as it represents “unclean” code coverage. The actual percentage is significantly lower. Work is ongoing to improve the reporting .) In addition, the test suites need to grow their testing scenarios to include the different ways users use WordPress.

4. “Beta Support” removal process

Once the above criteria are met, then the “beta support” classification can be removed for the next major WordPress release. Since only the most recent major branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". of WP is supported, previous versions of WP with “beta support” for a PHP version will remain, even if security updates are pushed to older branches after the fact.

The process for each PHP version:

  • Verify all of the above criteria are met.
    • Pull the site usage numbers to verify usage meets the criteria.
    • Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. all php-compatibility tickets for the PHP version (phpNN keyword) to ensure all tickets are resolved.
    • Verify backward compatibility.
  • Gather the list of accepted incompatibilities.
  • Identify and resolve dependency needs, such as a MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. change for Site Health to get the “recommended PHP” version via an APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. call.
  • When adding the next 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. to to the PHP Compatibility and WordPress Versions handbook page, do not add the * next to that specific PHP version. If there are incompatibilities, add ** next to the PHP version and list each incompatibility below the table.
  • Publish a Make/Core post that details what the compatibility change means for users and extenders.

5. Conclusion

This post presents a thoroughly referred recommendation for when to remove “beta support” from PHP 8 and newer versions. The criteria were a result of the feedback from several contributors listed below. However, it is only a proposal and is not concrete. Adjustments can be made to this proposal based on feedback from contributors in the comments below. If you have any thoughts, please do leave them below!

Unless there is a need to republish a modified version of this proposal for further feedback, after a consensus is reached and any needed approval from leadership to implement this proposal is received, the following action items would need to be addressed:

  • The Make WordPress Core handbook should be updated in the appropriate places to:
    • outline the criteria and process for reviewing each “beta support” PHP version with each WordPress major release.
  • Trac:
    • Add php-compatibility focus, which will be listed in “Contributor Focuses”. (Status: Done on Aug 1, 2023 ✅)
    • Contributors should scrub all tickets for PHP compatibility to (Status: Done as of Aug 8, 2023 ✅)
      • Add the php-compatibility focus with a description of “Relating to PHP forward and backwards compatibility. A phpNN keyword identifies the PHP version that introduced the incompatibility”.
      • Update the PHP version phpNN keyword, if necessary.
      • Determine the ticketticket Created for both bug reports and feature development on the bug tracker. status and next step toward resolution, including: close with a message why, complete, or get consensus on ones to be accepted as incompatible.
  • Any other action items identified while discussing this proposal.

Props to @jrf @joemcgill @mikeschroder @desrosj @azaozz @costdev @ironprogrammer @antonvlasenko for contributing to this post through providing feedback and proof-reading.

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