Tag Archives: PHP

John Blackbourn 9:24 pm on January 9, 2026
Tags: , , PHP   

Dropping support for PHP 7.2 and 7.3

Support for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 7.2 and 7.3 will be dropped in WordPress 7.0, currently scheduled for release in April 2026. The minimum recommended version of PHP will remain at 8.3, but the new minimum supported version of PHP will be 7.4.0.

The minimum supported version of PHP was last raised in July 2024 to 7.2.24. Since then usage of PHP 7.2 and 7.3 has dropped below 4% of monitored WordPress installations.

Historically, the project has used 5% as the baseline usage percentage that a PHP version must fall below before it can be considered for a well-earned retirement. Now that usage of PHP 7.2 and 7.3 combined has fallen well below that, the process to increase the minimum supported PHP version can proceed.

The goal of increasing the minimum supported version of PHP is to ensure the long-term maintainability of WordPress. The benefits to increasing the minimum supported PHP version manifest over time across multiple areas, including 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 and theme ecosystem, tooling and libraries for AI, the long-term perception of the WordPress project, developer relations, and eventually within the WordPress codebase itself, including its developer tooling and automated testing infrastructure.

Discussion around this minimum version bump can be found here on the Trac ticket.

What about PHP 8 and higher?

WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. is fully compatible with PHP 8.0 to 8.3 and is beta compatible with PHP 8.4 and 8.5.

A full breakdown of which PHP versions are compatible with each version of WordPress can be found in the WordPress Core Handbook..

What about security support?

Sites that are running PHP 7.2 or 7.3 will remain on the 6.9 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 WordPress once 7.0 is released. While only one branch officially receives security updates, fixes are backported down to WordPress 4.7 as a courtesy when possible.

What about the 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/ plugin?

The minimum supported version of PHP will also be increased to 7.4 in the Gutenberg plugin.

Going forward

There are no plans to bump the minimum supported PHP version on a set schedule. The Core team will continue to monitor PHP version usage and work with the Hosting team to encourage users and hosting companies to upgrade their versions of PHP as swiftly as possible. The 5% usage threshold will continue to be used as the standard for the foreseeable future.

At the time of publishing, the PHP version usage is as follows:

  • 8.5: 0.23%
  • 8.4: 4.90%
  • 8.3: 16.74%
  • 8.2: 27.29%
  • 8.1: 15.39%
  • 8.0: 5.69%
  • 7.4: 22.20%
  • 7.3: 2.04%
  • 7.2: 1.81%

Update PHP today

If you need more information about PHP or how to update it, check out this support article that explains more, guides you through the process, and provides instructions for contacting your web hosting provider for assistance.

Props to all those that have contributed to this discussion recently. Thanks to @desrosj, @westonruter, and @jorbin for feedback and proof-reading this post.

#7-0, #dev-notes, #php

Rodrigo Primo 11:22 am on December 5, 2025
Tags: , PHP,   

Coding Standard Proposal: Allow the use of the PHP short echo tag

Currently, the WordPress Coding Standard explicitly forbids the use of the PHP short echo tag (<?=) along with the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher short tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) (<?). This post proposes modifying this rule to allow the use of the short echo tag for single statements.

Motivation

Prior to PHP 5.4, it was possible to disable the PHP short echo tag (<?=) using the PHP short_open_tag ini directive. This meant that scripts using this tag could not be used in code that must work across different PHP installations, because the content within those tags may be printed instead of executed, which could lead to code exposure. For this reason, the WordPress Coding StandardsWordPress Coding Standards The Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook. May also refer to The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the PHP coding standards. forbid its use.

Since PHP 5.4, the short echo tag is always available, and changing the short_open_tag directive no longer affects it. WordPress dropped support for versions prior to PHP 5.6 in 2019, and since then raised the minimum supported PHP version to 7.2. Currently, according to WordPress.org stats, the percentage of active WP installs using PHP < 5.4 is 0.4% and the percentage of sites still using WP < 5.2 is 4.0%. Therefore, it is now safe to allow the use of short echo tags.

This tag is useful as it provides a more concise syntax for outputting values in template files. WordPress developers should be allowed to use it. An issue requesting this change is the most liked issue in the WPCSWordPress Community Support A public benefit corporation and a subsidiary of the WordPress Foundation, established in 2016. repository, indicating community support.

This proposal is about allowing the use of the short echo tag for single statements, not encouraging its use, so no immediate changes are required. In practice, this means that:

  • Existing open patches for CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. are not affected as either style is allowed.
  • Existing WP Core code and code in official WP themes should not be updated, as both styles are permitted. A patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. to enforce the use of short echo tags in all possible places will NOT be accepted.
  • However, a new official theme could choose to use short echo tags if desired.

Suggested change to the handbook

The suggestion is to modify the rule titled “No Shorthand PHP Tags” as follows:

New title: No PHP short open tag

Content:

Important: Never use the PHP short open tag (`<?`). Always use the full PHP open tag (`<?php`). Using the PHP short echo tag (`<?=`) is allowed, though short echo tag snippets should only contain a single statement.

Correct:

<?php … ?>
<?= esc_html( $var ); ?>

Incorrect:

<? … ?>

How to keep short echo tags forbidden in a given project

If this proposal is accepted, but a project wants to keep the short echo tag forbidden in its own codebase, it can do so by adding the following snippet to its PHPCSPHP Code Sniffer PHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on PHPCS. configuration after the WordPress standard is included:

<rule ref="Generic.PHP.DisallowShortOpenTag.EchoFound">
    <severity>5</severity>
</rule>

References

#codingstandards, #php, #wpcs

Props @dingo_d, @garyj, and @jrf for reviewing this post.

Rodrigo Primo 2:15 pm on October 23, 2025
Tags: , PHP,   

Coding Standard Proposal: Make it explicit that PHP files must use the .php extension

The current WordPress Coding Standard does not specify which file extensions should be used for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher files. This proposal establishes that only the .php file extension should be allowed for PHP files.

Motivation

While web servers like ApacheApache Apache is the most widely used web server software. Developed and maintained by Apache Software Foundation. Apache is an Open Source software available for free. and NginxNGINX NGINX is open source software for web serving, reverse proxying, caching, load balancing, media streaming, and more. It started out as a web server designed for maximum performance and stability. In addition to its HTTP server capabilities, NGINX can also function as a proxy server for email (IMAP, POP3, and SMTP) and a reverse proxy and load balancer for HTTP, TCP, and UDP servers. https://www.nginx.com/. can be configured to execute files with various extensions as PHP (e.g., .php3 and .phtml), the .php extension is the only one universally supported. If PHP files do not use the .php extension, there is a risk that scripts will not work on some web servers. For example, a default Debian installation using Apache and mod_php parses .php, .phtml, and .phar as PHP, whereas a default Fedora installation using Apache and mod_php parses only .php and .phar as PHP. This means that a 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 using .phtml file extensions will work on Debian, but not on Fedora (and may inadvertently render code in plain text). Therefore, for code portability, compatibility, and security, it should be agreed and checkable that only .php extensions are used for PHP files.

Another benefit of the change proposed here is that if all PHP files use the .php extension, we can be sure that they will be checked by tools like PHPCSPHP Code Sniffer PHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on PHPCS..

Proposed change to the handbook

Add a new item to the General section of the PHP Coding Standard Handbook as follows:

Title: File Extension

Content: PHP files must use the .php file extension.

References

This was originally proposed by Gary Jones in this WPCS issue.

#codingstandards, #php, #wpcs

Props @dingo_d, @garyj, and @jrf for reviewing this post.

John Blackbourn 12:56 pm on July 11, 2025
Tags: , PHP   

Proposal: PHPStan in the WordPress core development workflow

tl;dr Several official WordPress projects use PHPStan for static code analysisStatic code analysis "...the analysis of computer software that is performed without actually executing programs, in contrast with dynamic analysis, which is analysis performed on programs while they are executing." - Wikipedia of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher files as part of their development tooling and quality control. It’s used by thousands of WordPress plugins and themes to catch and prevent bugs before they’re committed. Let’s use it for WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. too.

What is PHPStan?

PHPStan is a mature, popular, and well-maintained static code analysis tool for PHP. From the PHPStan website:

PHPStan scans your whole codebase and looks for both obvious & tricky bugs. Even in those rarely executed if statements that certainly aren’t covered by tests.

You can run it on your machine and in CI to prevent those bugs ever reaching your customers in production.

PHPStan provides a means of scanning 100% of the PHP code in a project and identifying whole classes of bugs relating to code correctness within the context of the project as a whole, even before executing, testing, or writing tests for the code.

Another static code analysis tool that is already in wide use in WordPress is PHP_CodeSniffer (PHPCSPHP Code Sniffer PHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on PHPCS.), which checks adherence to coding standards that primarily relate to code formatting (although the WordPress Coding StandardsWordPress Coding Standards The Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook. May also refer to The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the PHP coding standards. provides additional rules for security, performance, and internationalisation best practices). PHPStan doesn’t care about coding style, it is un-opinionated and only tests the validity and correctness of code using increasingly strict levels of rules which allow it to be gradually introduced into an existing code base, even one the size and age of WordPress. It is complementary to PHPCS, not a replacement.

What is being proposed?

On #61175, @westonruter notes that:

PHPStan is a vital static analysis tool for identifying bugs in code. Previously it has been used to identify problems in core by manually running PHPStan on the core codebase.

This post proposes that:

  • PHPStan gets added as a development dependency to WordPress with the required settings and a configured baseline.
  • PHPStan analysis runs as a required check during CI on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ Actions.
  • Documentation on usage of PHPStan gets added to the core handbook.
  • These changes are implemented during the WordPress 6.9 development cycle.

@justlevine has kindly been working on the bulk of the core implementation, the baseline, and the CI workflow in this pull request on GitHub. Work on a documentation page for the handbook is yet to start.

The advantage of implementing a baseline is that PHPStan analysis can be introduced without having to make sweeping changes to the core codebase in order to pass all of the PHPStan rules from day one. The analysis will apply to code changes going forward, and existing issues in the baseline can continue to be addressed just as they have been in recent releases.

Benefits of PHPStan

Adopting PHPStan improves our codebase and development workflows in several ways:

  • Catch bugs in untested code: Unit, integration, and E2E tests only cover the code they execute. PHPStan can find bugs in code that isn’t explicitly tested, and make sure that code changes don’t introduce new bugs even in old code that has no tests.
  • Prevent logic and type errors: Unlike the enforcement of code formatting in PHPCS, PHPStan can trace the flow of code execution and identify critical errors that would otherwise only be caught at runtime. This is increasingly important as we work to maintain compatibility with the increasingly strict type safety requirements of PHP.
  • Improve contributor experience (for humans and 🤖): PHPStan provides immediate, automated feedback to contributors, helping new, veteran, and even agentic developers catch their mistakes and learn how to navigate the WordPress codebase. This reduces the burden on committers during code review and helps AI tooling use WordPress as accurately as possible.
  • Incremental adoption: PHPStan provides levels of strictness that can be adopted incrementally, as well as ways to ignore rules and baseline errors in preexisting code without interrupting the codebase. This keeps in line with the policy against unnecessary code refactoring.

Taken together, using PHPStan will help the project maintain and improve the quality and correctness of the WordPress codebase, paving the way for faster development, fewer bugs, and the safe adoption of newer PHP features over time.

While not a part of this proposal, PHPStan also offers benefits such as type narrowing, IDEIDE Integrated Development Environment. A software package that provides a full suite of functionality to software developers/programmers. Normally an IDE includes a source code editor, code-build tools and debugging functionality. hinting, documentation, and code validation features like generics, callable signatures, integer ranges, and lots more. These enhancements can be implemented as and when appropriate.

Concerns

When the implementation of native TypeScript in Gutenberg was proposed, there were some concerns raised:

  • The use of TypeScript could raise the barrier to entry for contributors.
  • TypeScript may not be here forever (ie. it could be outlasted by the underlying language).

If similar concerns are applied to the implementation of PHPStan:

  • Like any tool, there is an element of learning involved and there is always a risk of raising the barrier to entry, however that should not be a reason to refrain from introducing new tooling that provides an overall benefit to the project. Contributors who have not used PHPStan before may not be familiar with its error messages and may need guidance addressing issues that it reports, but handbook documentation, guidance from others, and general familiarisation over time will help. We’ll likely also find that the new generation of PHP developers is familiar with PHPStan due to its wide usage in many other popular and newer projects.
  • Unlike TypeScript, PHPStan isn’t a language itself that needs to be interpreted or transpiled in order to convert it to the PHP code that runs WordPress. If the PHPStan project were to disappear, WordPress would continue to work, the PHPStan checks could be removed, and another static analyzer could be implemented if necessary. That said, PHPStan is an active and well-maintained project so this shouldn’t be a concern.

You might have heard that PHPStan is only used to check type declarations, but this is not correct. In fact it only takes types into account when you start using it at level 3 or higher, and its scope is far beyond just type safety. Take a look through the PHPStan rule levels to see what it covers.

You might have heard that PHPStan only works for object-oriented codebases, this is also not correct. There is nothing inherent about PHPStan that restricts it to analyzing only OOP code. It works great with functional, procedural, and OOP code, with and without namespaces, and mostly whatever else you can throw at it, including excellent support for incomplete code.

There are two alternatives to PHPStan: Psalm and Phan. All three of these static code analysis tools are mature, popular, and well-maintained. PHPStan is being proposed because it’s the most popular out of these three tools (both inside and outside of the WordPress ecosystem), and because it’s the one that is most familiar to contributors to other official WordPress projects, and contributors and committers to WordPress core. Implementing PHPStan will not prevent developers using Psalm or Phan to scan their plugins, themes, or projects, or indeed to scan WordPress core using those tools too.

What about 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/?

The Gutenberg repo does not use PHPStan, however it would benefit from doing so in the same way that WordPress core will. A proposal to implement PHPStan into the development of Gutenberg can be found here. It’s not strictly part of this proposal, but the teams do need to determine whether this is a prerequisite.

Does this affect end users?

End users and website owners are not directly affected by this change. PHPStan itself does not affect PHP at runtime in much the same way that TypeScript doesn’t affect JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. at runtime. The purpose of this class of tooling is to allow developers to maintain code at a higher standard.

The effect this has on end users, consumers, developers, and web hosts is a higher quality application that is more maintainable, reliable, and correct, and will continue to be so over time. 

Next steps

  • This proposal can stay open for a couple of weeks as several northern hemispherical contributors and committers are enjoying well-earned holidays.
  • Work needs to continue on the pull request that adds the configuration, baseline, and CI.
  • Continued communication needs to happen with the Gutenberg team to determine whether PHPStan scanning in Gutenberg is a prerequisite.
  • A documentation page for the handbook needs to be drafted.

The latest version of PHPStan will be used (currently 2.1.17). This requires PHP 7.4 or greater which means the implementation of PHPStan depends on the minimum supported version of PHP in WordPress being increased to 7.4, which is under consideration for WordPress 6.9. Therefore the 6.9 development cycle needs to be announced before this change can be implemented. In the meantime there is no need to be concerned about PHPStan failures on PHP 7.2 and 7.3 in the pull request.

Further technical details can be found on ticketticket Created for both bug reports and feature development on the bug tracker. #61175.

Elsewhere

If you’re curious about how other projects use PHPStan, here are some links.

PHPStan is used by thousands of WordPress plugins, themes, tools, and projects, and 25,000 packages across the PHP ecosystem.

It’s been in use for years by several other official WordPress projects, including:

It’s also been used previously by individual contributors to remediate many issues in WordPress core, most recently in #63268.

If you are interested in using PHPStan as part of the development tooling in your 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, theme, or project, you should take a look at the phpstan-wordpress package by Viktor Szépe which provides WordPress-specific extensions for PHPStan.

Acknowledgements

Thanks to @justlevine @westonruter @swissspidy @sergeybiryukov and others for their work on PHPStan fixes in recent releases and for helping with this proposal.

#developer-experience, #php

John Blackbourn 10:19 am on July 7, 2025
Tags: PHP, ,   

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

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

John Blackbourn 9:24 pm on April 8, 2024
Tags: , , PHP   

Dropping support for PHP 7.0 and 7.1

Support for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 7.0 and 7.1 will be dropped in WordPress 6.6, scheduled for release in July 2024. The new minimum supported version of PHP will be 7.2.24. The recommended version of PHP remains at 7.4 or greater.

WordPress currently supports PHP version 7.0 or greater. The minimum supported version was last adjusted in WordPress 6.3 in August 2023, and since then usage of PHP 7.0 and 7.1 has dropped to a combined 2.45% of monitored WordPress installations as of April 2024.

There’s no concrete usage percentage that a PHP version must fall below before support in WordPress is dropped, but historically the project maintainers have used 5% as the baseline. Now that usage of PHP 7.0 and 7.1 combined is well below that at 2.45%, the process to increase the minimum supported PHP version in this release can move forward.

The benefits to increasing the minimum supported PHP version manifest over time and in multiple places, including within 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 and theme ecosystem, within the long term perception of the WordPress project, within developer relations, and over time within the WordPress codebase and its developer tooling.

Discussion around this minimum version bump can be found here on the Trac ticket.

What about PHP 8?

WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. is compatible with PHP 8.0 and 8.1 with exceptions. Support for PHP 8.2 and PHP 8.3 is considered 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. since WordPress 6.4. Please see the PHP Compatibility and WordPress Versions page in the handbook for full information.

What about security support?

Sites that are running PHP 7.0 or 7.1 will remain on the 6.5 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 WordPress which will continue receiving security updates as it does currently. The current security policy is to support WordPress versions 4.1 and greater.

What about the 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/ plugin?

The Gutenberg plugin, which is used for development of the 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. editor, has a separate release schedule from WordPress core and officially supports the two most recent releases of WordPress. The Gutenberg development team will likely also increase the minimum supported version of PHP to 7.2 in time for WordPress 6.6. See this issue on the Gutenberg repo for when this was last changed in WordPress 6.3.

Going forward

There are no plans to bump the minimum supported PHP version on a schedule. The core team will continue to monitor usage of PHP versions and work with the hosting team to encourage users and hosting companies to upgrade their versions of PHP as swiftly as possible. The 5% usage baseline will continue to be used for the foreseeable future.

The PHP usage stats as of April 2024 look like this:

  • 8.3: 1.20%
  • 8.2: 12.07%
  • 8.1: 16.34%
  • 8.0: 12.25%
  • 7.4: 42.80%
  • 7.3: 4.79%
  • 7.2: 3.80%
  • 7.1: 0.95%
  • 7.0: 1.50%

Update PHP today

If you need more information about PHP or how to update it, check out this support article that explains more and guides you through the process.

Props to all those that have contributed to this discussion recently. Thanks to @chanthaboune for feedback and proof-reading this post.

#6-6, #dev-notes, #php

Juliette Reinders Folmer 3:28 pm on August 21, 2023
Tags: , , PHP,   

WordPressCS 3.0.0 is now available

A wapuu in a dark grey hoodie using a silver coloured laptop with the WordPress logo on the laptop cover.
Image credits: Marktimemedia

This post announces the immediate availability of the long-awaited WordPressCS 3.0.0 release.

This is an important release which makes significant changes to improve the accuracy, performance, stability and maintainability of all 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., as well as makes WordPressCS much better at handling modern PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher.

Most rules which were proposed in the Make post from March 2020 have been added to the Coding standards guidelines.
Proposed rules which yielded a lot of discussion or to which objections were raised, have not been added.
The intention is to publish separate Make posts for each of these over time, to discuss these more controversial proposals further.

For a large number of the new rules, sniffs have been added to WordPressCS to enforce these rules.
More sniffs may be added in future WordPressCS releases to comprehensively cover the new and updated rules.

New architecture

WordPressCS previously had only one runtime dependency, which was PHP_CodeSniffer and end-users would need to manually register WordPressCS with PHP_CodeSniffer (or use a Composer 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 to do so).

As of WordPressCS 3.0.0, WordPressCS will have four run-time dependencies and because of this, Composer will be the only supported way to install WordPressCS.

Mind: it is still perfectly possible to install WordPressCS and its dependencies without using Composer. It is just not an installation method for which support will be provided.

The image shows the new architecture of WordPressCS 3.0.0. Everything is build on top of PHP_CodeSniffer - which comes with the Generic, PEAR, PSR1, PSR2, PSR12, Squiz, and Zend standards. On top of PHP_CodeSniffer, there is the PHPCSUtils package. And then there are the WordPressCS and PHPCSExtra packages which both are build on top of PHPCSUtils. WordPressCS comes with the WordPress, WordPress-Core, WordPress-Extra and WordPress-Docs rulesets. PHPCSExtra comes with the Universal, NormalizedArrays and Modernizer rulesets. To the side of this stack, it shows another package: the Composer PHPCS Plugin. This package makes sure that all external standards are automatically and correctly registered with PHP_CodeSniffer.

PHPCSUtils is a set of utility functions for use with PHP_CodeSniffer.
PHPCSExtra is an additional set of sniffs.
Composer Installer is a Composer plugin which will make sure that WordPressCS, PHPCSUtils as well as PHPCSExtra will be registered correctly with PHP_CodeSniffer.

New, non-WordPress-specific, sniffs will now be added to PHPCSExtra, while all WordPress-specific sniffs continue to be maintained in WordPressCS.
Some of the pre-existing WordPressCS sniffs, which could benefit the wider PHP community, have been removed and replaced by similar (and improved!) sniffs which were added to PHPCSExtra.

Upgrading to WordPressCS 3.0.0

WordPressCS 3.0.0 contains breaking changes, both for people using ignore annotations, people maintaining custom rulesets, as well as for sniffsniff 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. developers who maintain a custom PHPCSPHP Code Sniffer PHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on PHPCS. standard based on WordPressCS.

Aside from the changelog, WordPressCS 3.0.0 comes with detailed upgrade guides for both end-users/ruleset maintainers as well as a separate upgrade guide for developers who have built a coding standard on top of WordPressCS.

Please read the provided documentation carefully before you upgrade.

WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. will upgrade to WordPressCS 3.0.0 in the near future as well. Follow TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #59161 if you want to stay informed and be sure to run composer update --with-all-dependencies once the patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. has been committed to benefit from the latest & greatest sniff goodies.

Why did it take so long for this release to be “ready” ?

This release is basically the result of four big projects combined. It wasn’t necessarily the intention when work on WordPressCS 3.0.0 started that these projects would be combined into one release, but internal and external influences had an impact on timing, which made it so.

Also, please keep in mind that this project is basically maintained by a very, very small group of unpaid volunteers, who also have real jobs to do.

The four big projects we are talking about are:

  1. A big refactor.
  2. Adding new rules based on the Make post from March 2020.
  3. Making the sniffs compatible with PHP 7.4, 8.0, 8.1 and 8.2 (* 8.2 in so far currently possible as PHP_CodeSniffer doesn’t fully support all 8.2 syntaxes yet).
  4. Improving the available documentation.

Now let’s talk a little about each of these.

The refactor

WordPressCS previously had only one runtime dependency, which was PHP_CodeSniffer and end-users would need to manually register WordPressCS with PHP_CodeSniffer (or use a Composer plugin to do so).
PHP_CodeSniffer offers some limited “utility” functions for sniffs and some basic abstracts.

But… WordPressCS – and other external standards, like PHPCompatibility – wanted more utility functions and better abstracts to be available, so these projects added their own and these utilities then had to be maintained in each of those projects.

To improve this situation, it was originally proposed for the non-standard specific utilities to be added to PHP_CodeSniffer. After nearly a year of work on this, lots of discussion and waiting, it was eventually decided in the summer of 2019 that these utilities should live in a separate project.

Moving this work to a separate project was a setback and meant having to rework a lot.
This separate project was published as PHPCSUtils in January 2020.

By that time, PHP 8.0 also started to come into play and it was becoming very clear that this would involve lots of changes for Coding Standards projects and both PHP_CodeSniffer, as well as the utilities, would have to be made compatible with PHP 8.0 before a new version of WordPressCS could be released.

In practical terms, most non-WordPress-specific utility functions are now available via PHPCSUtils.
The remaining utility functions, i.e. the few exceptions + the WordPress-specific utilities, have all been moved to separate “helper” classes and traits to make the code more re-usable for sniffs not based on the WordPressCS specific base Sniff class.

New rules

The Make post from March 2020 proposed a lot of new rules, which resulted in a healthy discussion on the post and save for a few rules, most of the new rules met with approval.

This meant two things:

  1. Research needed to be done whether there were any pre-existing sniffs that could be used to implement the approved rules.
  2. For anything for which no sniff existed, a new sniff would need to be written.

A whopping 35 new sniffs were written for this release, 32 of these were added to PHPCSExtra, and 3 to WordPressCS itself.

To see a list of all the rules included in a particular standard, use:

vendor/bin/phpcs -e --standard=WordPress

(you can replace WordPress with, for instance, WordPress-Core or Universal or PSR12 to see the sniffs included in a particular standard)

Making sniffs compatible with PHP 7.4, 8.0, 8.1 (and 8.2)

Making a PHP project compatible with a new PHP version is one thing, doing so for a static analysis tool is something else altogether.

Making sniffs compatible with a new PHP version, basically involves three things:

  1. Making sure the existing code will run on the new PHP version without errors or notices.
  2. Making sure that sniffs do not throw a false positive/negative when confronted with a new syntax.
    Example: if a sniff looks for function calls to analyse and excludes method calls – function calls preceded by a -> or :: -, for PHP 8.0, these sniffs needed to be adjusted to also exclude function calls preceded by the nullsafe object operator ?->.
  3. Add explicit support for new PHP features.
    Example: if a sniff would examine the name of a class-like structure, like a class, interface, or trait, the sniff would probably benefit from new code to also examine the names of PHP 8.1 enum structures.

Now, aside from 1, for 2 and 3, WordPressCS has a BIG dependency on PHP_CodeSniffer itself as PHP_CodeSniffer needs to support the new syntaxes first before an individual sniff can start to support them.

At the time work started for WordPressCS 3.0.0, PHP_CodeSniffer didn’t fully support PHP 7.4 yet, which added quite some new syntaxes and then PHP 8.0, 8.1 and 8.2 came along adding yet even more.

PHP 7.4, 8.0, 8.1, 8.2 added more new syntaxes to PHP than all of the PHP 5 and 7 releases before it combined.

Now you may ask yourself: “Why should the sniffs take all those new PHP syntaxes into account ?” After all, WordPress still supports PHP 7.0 (PHP 5.6 prior to WP 6.3), so those syntaxes cannot be used in code written for WordPress Core…

Well, the WordPress Coding StandardsWordPress Coding Standards The Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook. May also refer to The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the PHP coding standards. are a community standard and WordPressCS codifies this into automated checks and as such, WordPressCS is not only used by WordPress Core, but also by the wider WordPress community, including agencies, plugin and theme authors etc.
And plugins and themes may have a higher minimum supported PHP version, especially when we’re talking in-company/closed source plugins and themes.

Aside from that, sooner or later, WP will raise the minimum supported PHP version to a version including these new syntaxes, so the work would need to be done anyway and it’s easier to do this when what’s changed in PHP is still fresh in our minds.

So, a new waiting game started, where PHPCS needed to be updated first, then PHPCSUtils and only then could support for the new syntaxes be added to WordPressCS.

Safe for the PHP 8.2 Disjunctive Normal Form Types, which isn’t supported yet by PHP_CodeSniffer itself, all new syntaxes which were introduced in recent PHP versions are now taken into account in all sniffs in as far as our (my) imagination reached.

If you run into a situation where a sniff appears to not be fully compatible with modern PHP syntaxes yet, please open a bug report.

Improving the documentation

PHPCS has a built-in sniff documentation feature. Until recently, WordPressCS didn’t really support this feature and WordPress sniffs didn’t provide the documentation needed.

A start was made to add documentation to sniffs during the contributor dayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. 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. Europe 2019.

This effort has continued during the WordPressCS 3.0.0 cycle and the majority of sniffs used by and provided by WordPressCS now include documentation with code samples of what a sniff expects.

To view the documentation for any of the included standards use:

vendor/bin/phpcs --generator=Text --standard=WordPress

(you can replace WordPress with, for instance, WordPress-Core or Universal or PSR12 to see the documentation for other standards)

The future of WordPressCS

While WordPressCS is currently in a good place with this release, this won’t last long with the pace at which PHP is going.

WordPressCS 3.0.0 has costs thousands of hours of work and the vast majority of work has been done by one, mostly unpaid, contributor, with code review support from two fellow maintainers.

If we are being realistic, the bus factor of WordPressCS is 1, which is the most dangerous situation for any project to be in.

A large part of the WordPress community, including WordPress Core, relies heavily on the WordPress Coding Standards for code quality and security checks and while the community has been pretty vocal with copious complaints about the delayed release, barely anyone has stepped up and actually contributed.

The majority of the work for WordPressCS requires specialized knowledge. Knowledge which can be learned with enough time investment, but in recent years nobody has stepped up to do so.

This is an unsustainable situation and it ends now.

Unless funding is found to continue maintaining WordPressCS and its dependencies, the future is bleak and maintenance will be halted.

Let this be a call to action for the corporate/agency users of WordPressCS to come together and figure out a way to fund the continued maintenance and development of WordPressCS as that one person on which the whole project, including all dependencies, leans, is done with the current status quo.

If you want to help change this situation, please reach out to the WordPressCS maintainer team (@jrf, @GaryJ, @dingo_d) via WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. to discuss.

Props to @GaryJ, @dingo_d and @milana_cap for reviewing the post before publication.

#modernizewp, #codingstandards, #php, #wpcs

John Blackbourn 5:45 pm on July 5, 2023
Tags: PHP   

Dropping support for PHP 5

Support for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 5 will be dropped in WordPress 6.3, scheduled for release on August 8th 2023. The new minimum supported version of PHP will be 7.0.0. The recommended version of PHP remains at 7.4 or greater.

WordPress currently supports PHP version 5.6.20 or greater. The minimum supported version was last adjusted in WordPress 5.2 in 2019, and since then usage of PHP 5.6 has dropped to 3.9% of monitored WordPress installations as of July 2023.

There’s no concrete usage percentage that a PHP version must fall below before support in WordPress is dropped, but historically the project maintainers have used 5% as the baseline. Now that usage of PHP 5.6 is well below that at 3.9% and dropping by around 0.1% every few weeks, plans to increase the minimum supported PHP version can move forward.

The benefits to increasing the minimum supported PHP version manifest over time and in multiple places, including within 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 and theme ecosystem, within the long term perception of the WordPress project, within developer relations, and over time within the WordPress codebase and its developer tooling.

Discussion around this minimum version bump can be found here on the Trac ticket.

What about PHP 8?

Support for PHP 8.0, 8.1, and 8.2 in WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. is very good, and a proposal for the criteria for removing the “beta” support label for each new PHP version has been published.

What about security support?

Sites that are running PHP 5.6 will remain on the 6.2 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 WordPress which will continue receiving security updates as it does currently. The current security policy is to support WordPress versions 4.1 and greater.

What about the 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/ plugin?

The Gutenberg plugin, which is used for development of the 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. editor, has a separate release schedule from WordPress core and officially supports the two most recent releases of WordPress. This means that the Gutenberg plugin will continue to support PHP 5.6 for the time being, most likely until WordPress 6.4 is released. See this issue on the Gutenberg repo for further information.

Going forward

There are no plans to bump the minimum supported PHP version on a schedule. The core team will continue to monitor usage of PHP versions and work with the hosting team to encourage users and hosting companies to upgrade their versions of PHP as swiftly as possible. The 5% usage baseline will continue to be used for the foreseeable future.

The PHP usage stats as of July 2023 look like this:

  • 8.2: 2.11%
  • 8.1: 9.37%
  • 8.0: 14.05%
  • 7.4: 51.13%
  • 7.3: 7.92%
  • 7.2: 6.29%
  • 7.1: 1.38%
  • 7.0: 2.05%
  • 5.6: 3.93%

Update PHP today

If you need more information about PHP or how to update it, check out this support article that explains more and guides you through the process.

Props to all those that have contributed to this discussion recently. Thanks to those who provided feedback and proof-reading of this post: @azaozz @chanthaboune @flixos90 @hellofromtonya @javiercasares @joemcgill @jorbin @jrf @peterwilsoncc @sergeybiryukov

#php

Tonya Mork 3:40 pm on June 20, 2023
Tags: PHP, ,   

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