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

Dropping support for PHP 5

Support for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 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

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.


Officially WordPress Core currently provides “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” (or “beta compatibility”) for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 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

Proposal: Disallow assignments in conditions and remove the Yoda condition requirement for PHP

After discussion with several coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committers and WordPress leads, the title and the contents of the text were changed to clarify that this is a proposal and not a decision set in stone.

This proposal is the continuation of the long discussion on the WordPress Coding Standards (WPCS) repo.

Yoda conditions (or Yoda notation) is the programming style where the parts of an expression in the condition are reversed from the ‘typical’ order.

In a large part of the world, the natural reading order is left to right (LTR). This is what most programming languages adhere to. That means the variable assignments or echo/print statements are written with the variable first:

$post_type = 'post';

echo $post_type;

With the same idea in mind, conditions can also be written left to right, like:

if ( $post_type == 'post' ) {
    $category = get_the_category();
}

With Yoda conditions applied, the above condition would be written as:

if ( 'post' == $post_type ) {
    $category = get_the_category();
}

The idea behind it is that writing the value on the left side of the condition will prevent accidentally assigning the value to the variable since assignments can’t be made to values.

if ( $post_type = 'post' ) {
    $category = get_the_category();
}

While seemingly helpful at first glance, the obvious problem with them is the decreased readability of code, especially for people with reading disabilities such as dyslexia.

How we got here

When the handbook rule about Yoda conditions was introduced there was barely any static analysis tooling available in the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher world. The only ‘foolproof’ way to prevent accidental assignment in conditions was to invert the order of the value being checked and the variable.

Automated checking for assignments in conditions via PHP_CodeSniffer (PHPCSPHP Code Sniffer PHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on PHPCS.), the underlying tooling for WPCSWPCS The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the WordPress Coding Standards. May also be an acronym referring to the Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook., became available in 2017. Moreover, the current 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. enforcing Yoda condition in the WPCS doesn’t protect against accidental assignments in conditions.

Today there is tooling in place that can help with identifying assignments in conditions, making the Yoda rules obsolete.

Keep in mind that strict comparisons (===) are already strongly encouraged and a part of the WordPress-Core ruleset (warning), making accidental assignments even less likely.

A thorough analysis was made by Lucas Bustamante in the WPCS ticketticket Created for both bug reports and feature development on the bug tracker. on the impact this could have on the plugins in the WordPress directory. The analysis showed that Yoda conditions are used in 18.02% of the plugins, so the majority of 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 developers are using non-Yoda conditions.

What to do next?

The discussion in the WPCS ticket is long and opinionated, but comes down to these points:

Disallow Yoda condition

  • Drop the handbook rule that requires Yoda conditions and instead explicitly disallow using them.

Remove Yoda condition as a requirement

  • Discourage, but don’t disallow Yoda conditions. Just don’t report if the code is or is not using Yoda conditions. The rule would also be dropped from the handbook.

In both cases, assignments in conditions will still be checked for and forbidden.

Impact on the Core code

Disallowing Yoda conditions for WordPress Core would mean that all existing patches on open tickets for Core would need to be revisited and fixed accordingly, which could burden the contributors.

Running the same analysis as Lucas did for plugins, over the WordPress Core, there were 5427 Yoda conditions, and 312 non-Yoda conditions.

Luckily, these are violations that can be automatically fixed using phpcbf tool, but care should be taken to check if all the violations were correctly fixed.

If Yoda conditions are discouraged (option 2), and the existing Yoda conditions in the Core code remain, that would mean less work for the Core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org., but also would add lots of inconsistencies in the Core code (mixed Yoda and non-Yoda conditions).

Next steps

The chosen way forward is to remove the Yoda condition as a requirement (remove it from the handbook) but not disallow it for the time being.

For WPCS, that would mean the removal of the Yoda conditions requirement (and sniff) in WPCS 3.0, with a notice that non-Yoda conditions will start to be required in WPCS 4.0 version.

Work is currently actively ongoing to prepare for the WPCS 3.0.0 release. There will be a minimum of six months between the 3.0.0 and the 4.0.0 release to allow time for Core and other projects to adjust.

Once WPCS 4.0.0 version is released, a one-time-only auto-fix of all the remaining Yoda conditions in Core will be made, and any patches to the Core which go in after that will have to use non-Yoda.

How to enforce the non-Yoda conditions in your code

If you are a WordPress plugin or theme developer, and you’d like to enforce non-Yoda conditions in your code, you can use the Generic.ControlStructures.DisallowYodaConditions sniff. In your phpcs.xml.dist file you should add the following sniff:

<?xml version="1.0"?>
<ruleset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Example Project" xsi:noNamespaceSchemaLocation="https://raw.githubusercontent.com/squizlabs/PHP_CodeSniffer/master/phpcs.xsd">

    <!-- Your custom rules. -->

    <!-- Disallow Yoda conditions in your codebase. -->
    <rule ref="Generic.ControlStructures.DisallowYodaConditions"/>

</ruleset>

If you want to change the Yoda conditions to non-Yoda conditions, use the phpcbf tool (part of PHPCS) with the Slevomat coding standards. Specifically, the SlevomatCodingStandard.ControlStructures.DisallowYodaComparison sniff that has the fixer for the Yoda conditions.

Props to Juliette Reinders Folmer and Gary Jones for the proofreading and adding valuable feedback on the text. Also, a big props to Lucas Bustamante for the impact analysis on WordPress plugins.

#codingstandards, #php, #wpcs

Call for testing: PHP 8.0

A long-standing goal of the WordPress project is to be compatible with new versions of PHP on their release day. The next major version of PHP (version 8.0) is currently scheduled for release on November 26, 2020. WordPress Core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. are working to ensure PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 8.0 is supported in the next major version of WordPress (version 5.6), which is currently scheduled to be released on December 8, 2020.

PHP 8.0 has been in the making for some time and brings a lot of exciting features. But because PHP 8.0 is a major version release, it also includes some backward incompatible changes. Because of this, a great deal of both manual and automated testing is needed in order to ensure the WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. codebase is ready for PHP 8.0.

Even though WordPress 5.6 will add support for PHP 8.0, no changes will be made to the minimum required version of PHP at this time. Any changes made to provide support for PHP 8.0 will be done in a way that maintains backward compatibility for all versions of PHP supported by WordPress (currently to PHP 5.6.20).

Your help is needed to test WordPress on PHP 8.0! While contributors are working on addressing incompatibilities that can be identified by looking at the PHP release notes and upgrade guides, some issues will need to be found through manually testing.

Timeline for testing

Since changes for PHP 8.0 compatibility may be extensive, November 17, 2020 (the current planned date for 5.6 RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1) should be seen as the cut off date for the change to be included in WordPress 5.6. To ensure that changes receive proper testing, patches and pull requests should be submitted as soon as possible.

How to test WordPress on PHP 8.0

There are a few ways that you can test WordPress on PHP 8.0. Some more experienced developers may prefer to install PHP 8.0 manually on their own. But below are instructions for what is likely the quickest and easiest way for most contributors to get set up with PHP 8.

Local WordPress Core Docker environment

The WordPress development repository includes the tools needed to easily spin up a local Docker environment for developing WordPress. Here’s how to get started using this method.

  • Make sure Docker is installed on your machine and running.
  • Checkout the development repo using GIT or SVN.
  • Edit the .env file in the clone to change LOCAL_PHP=latest to LOCAL_PHP=8.0-fpm (or run export LOCAL_PHP=8.0-fpm in the command line window you are using). If you like to test locally using the build directory, also change LOCAL_DIR to build (or run export LOCAL_DIR=build).
  • Install NPM dependencies by running npm install.
  • Build WordPress using npm run build:dev (or npm run build if you prefer to test locally using the build directory)
  • Start the Docker environment by running npm run env:start.
  • Install WordPress in the Docker container by running npm run env:install.

You will then be able to access the site at localhost:8889 in your browser. As new development versions of PHP 8 are released (rc2, rc3, etc.), the containers will be updated. To ensure you are running the latest version of the PHP 8 container, you can run npm run env:pull. It is recommended that you do this before starting the container anytime you are testing WordPress on PHP 8.

More information on the local Docker setup for developing WordPress can be found in the initial Make Core blog post.

Ways to test

  • Use WordPress to test default Core functionality.
  • Write new unit tests that confirm specific PHP 8.0 features or breaking changes work (or don’t) as expected.
  • Write new tests for areas of the codebase that does not have sufficient test coverage.
  • Test your favorite plugins and themes for issues.

Reporting issues

If you discover something that you believe to be a PHP 8 compatibility issue, please create 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. report on the WordPress Core instance of Trac. Because this is an ongoing effort, it’s possible an issue you have found is already being tracked, is currently being worked on, or has already been fixed. To avoid duplicate reports, please look through pre-existing tickets. The best way to do this is by looking at tickets with the php8 keyword.

Please be sure to provide as many details as you can when creating a ticketticket Created for both bug reports and feature development on the bug tracker. and provide steps that are as specific as possible so that other contributors can quickly and easily reproduce the problem.

More ways to help

  • Head over to the php8 keyword report on WordPress Trac and find a ticket that interests you.
  • Give feedback, write 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., or test a patch!
  • Inform others that help is needed to test WordPress on PHP 8.0.

To ensure changes receive the necessary testing, it’s best to fix PHP 8.0 compatibility issues as early as possible during the WordPress development schedule. The 5.6 RC1 date (November 17th, 2020) should be considered the final cut off for changes. If additional critical PHP 8.0 issues are found during the RC period, they should receive tickets and patches and will be evaluated on a case by case basis. But, they will not be guaranteed to make the 5.6 release (usually, only regressions are addressed during the RC period). 

Thanks in advance for your help preparing WordPress for PHP 8.0!

Props @sergeybiryukov, @daisyo, @desrosj, and @andreamiddleton for proofreading and peer review.

#php, #testing

Proposal: Dropping support for old PHP versions via a fixed schedule

While most people here will probably mostly know me as a (PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher) developer, I actually have a background in business studies, so when Matt Mullenweg reached out to me to continue the conversation about WordPress dropping support for older PHP versions in an in-person call, I decided to put my business acumen to use and see if I could come up with a proposal which would make sense from a business point of view for all parties involved, be it the amazing contributors to the WordPress project, the web hosts, 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 builders, the web agencies and the users who often run their business via their WordPress website.

In short, I’m proposing a fixed schedule in which every PHP version is supported for five years. Additionally each WordPress release will receive security updates for four years. In effect, this means that users, at a stretch, would be able to run on one specific PHP version for nine years.

A fixed schedule will make this whole process transparent and will allow all parties to plan for the version drops accordingly.

With Matt’s blessing, I’m posting this proposal here on Make to gauge the reactions of the wider community to my idea.

Please feel very invited to leave a comment whether you agree with the proposal or not.
Mentioning what your involvement is with WordPress and how this proposal will impact you in a positive or negative way, would be very valuable input for further discussions on this.

Chicken vs egg

The situation we are currently in, is basically one of “Which came first, the chicken or the egg ?”.

Current situation: Classic Chicken vs Egg


WordPress doesn’t drop support for older PHP versions until enough users have moved over to newer PHP versions and a significant enough share of the WP users don’t upgrade their PHP version until they really have to because WordPress drops support for the version.

This is circular logic, which as most developers know, never ends well as you end up in an infinite 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. where, in the end, neither moves forward.

So who are these users who don’t upgrade ?

Well, while we can’t know for sure, if we look at the figures, we can see some patterns:

Pie chart with the statistics for which version of WordPress is used by which percentage of users.
In the chart it is highlighted that there are 3.7% of users still on WP 5.1 (PHP stragglers), a whopping 10.6%on WP 4.9 (Gutenberg dislikers) and a similar percentage of users on WP versions older than WP 4.9, a  lot of which may be zombie-sites.

Take note of the fact that the percentage of users on WP 5.1 who didn’t upgrade yet is relatively small and only part of that can be attributed to the PHP < 5.6 version drop in WP 5.2.

So let’s look at some likely personas for users who don’t upgrade:

Image showing four persona's:
1. The zombie thinking "Huh, what notice ? what website ?"
2. The overwhelmed person thinking "Admin notices are so noisy, I just ignore them all".
3. The laid-back person thinking "No rush, I'll do it later (when it's needed)".
4. The business person thinking "We'll take the costs last minute and not a minute before".

We have the “zombie” persona, sites which are still online, but are not actively updated anymore.
These can be, for instance, sites which were linked to a specific event or other date-related topic which are still online for historical reasons, aggregate sites which automatically re-post from other sites without adminadmin (and super admin) involvement, or spam sites etc.

We have the “overwhelmed” persona, who blatantly ignores all admin notices. We all know why and how this happens. The multitude of notices in the admin area once a site has a few plugins and a theme installed trained this user to ignore them.

Then there is the “laid-back” persona, who has seen the notices, but doesn’t feel any urgency until they can’t update their site anymore.

And lastly, the “business” persona, often with a custom theme and a number of custom build plugins who’d rather move the costs of upgrading those to the next accounting year.

As for the user who feels out of their depth – amazing work has been done by the #site-health team to help those out.
For those users, I like to use the car analogy:

A website is something users will generally use regularly and expect to “just work”. So let’s make the comparison with something else a lot of people use regularly and expect to “just work”.

Say a car. Similar to WP, when one gets themselves a car, you need to familiarize yourself a little with how it works (interface/admin), but then it just runs. You put in petrol regularly (WP updates) to keep it running. Then once in a while, it needs a proper service. Now you have a choice: either you learn how to service a car yourself (read the site health materials and follow them up) or you go to a garage (hire a specialist) to do it for you.
And if you really don’t want to be bothered with all that, you lease a car instead (managed WP hosting solution).

Along the same lines: if you ignore the warning lights in a car (site health admin notices), you can’t pretend to be surprised that at some point it will break down (gets hackedhacked /can’t upgrade anymore). If was your responsibility as a user to act on them after all.

But Juliette, get to the point: how do you think we can get out of this situation ?

Ok, so here goes: I propose a fixed (rolling) schedule for dropping support for older PHP versions.

A fixed schedule means that such version bumps become predictable and with them becoming predictable, they become manageable and plannable.

These last two qualities are extremely important as all parties involved will know well in advance what they need to do and when it should be ready.

The current uncertainty over what WordPress will do leads to inaction, as we saw with two of the example personas, and we can counter that with becoming predictable and reliable with regards to the PHP version bumps.

So I propose that, as of now, we start dropping support for the PHP minor which is more than five years old each December, or if there is no release in December, in the WordPress release which is being worked on at that time.

That would currently look something like this, with the numbers at the top being the version of the WordPress release that December and the numbers at the bottom being the new minimum supported PHP version.

Timeline from December 2016 to December 2024 showing the WordPress version released that December and the minimum supported PHP version as of that WordPress version.
WordPress 5.6 in December 2020 would get a minimum of PHP 7.1.
WordPress 5.9 in December 2021 would get a minimum of PHP 7.2, etc
Below the timeline it shows for each PHP version when it was released and until when it will be supported by WordPress.

Keep in mind that, per the currently proposed schedule, the new minimum supported PHP version would always already be a version which is no longer actively supported by the PHP project, nor does it have security support anymore at the time it becomes the new minimum supported version for WordPress.

For example, PHP 7.1 was released in December 2016. Active support for PHP 7.1 stopped beginning of December 2018 and security support stopped on December 1, 2019. And based on the current proposal WordPress would still support it until December 2021.

But all those users on old WordPress versions…

Well, WordPress has always had a very liberal policy for backporting security fixes, so as part of this proposal, I’d like to suggest that the WordPress project makes a hard commitment to continuing to backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. security fixes for WordPress versions up to four years back.

Timeline from December 2016 to December 2024 showing that during the lifetime of the upcoming WordPress 5.6 release, the 5.6 release would get active support, but that WordPress 4.7 (released December 2016) up to WordPress 5.5 (released this month) would get security releases (if needed).

What that would come down to in practice, is that if a user would always want to use the latest and greatest version of WordPress with the minimum of effort, they would need to ensure their PHP version is updated once every five years.

Slide: Example: user on PHP 7.4
* WordPress will offer 5 years of support for the PHP version.
* WordPress will offer 4 more years of security updates for WP versions before the version bump dropping PHP 7.4.
* In total this adds up to 9 years of support.

And if they don’t mind lagging behind a little in their WordPress version, they could even get away with only updating their PHP version once every nine years and still have their website running on a secure version of WordPress.

Now how does that sound ? Is that a liberal enough policy ?

Note: security fixes are currently back-ported as far back as WordPress 3.7. With this proposal, the minimum version of WordPress still receiving security fixes would not longer be a fixed version, but would change to a rolling number.

But what about the users currently on old WordPress versions ?

To solidify the commitment to making this as transparent as possible for the users, I propose we backport the PHP admin notice from the site-health project to the older, still currently security supported, WordPress versions, so that those users will be informed when they log in to their website.

Alongside of that we could ramp up the site-health notices based on this fixed schedule of version drops and committed security fix support.

Slide showing an "Urgency nudges" proposal:
* For websites running on a PHP versions no longer actively supported, an admin notice will be shown.
* As of six months before the planned drop of a PHP version, the admin notice on those sites would change colour to draw more attention to it.
* After the PHP version drop, the proposal is to show a big pop-up on admin login for the first and second year after. The notice is dismissable but will come back once a month.
* For the third and fourth year after support for the PHP version has been dropped, this pop-up will show every time an admin logs into the website.

So… what do you think ? I eagerly await the reactions of you all!

Props to @sergeybiryukov, @joostdevalk and @matt for looking this article over before publication.

#core, #core-php, #php, #request-for-comment

PHP related improvements & changes: WordPress 5.5 edition

As part of an ongoing effort to improve compatibility across all supported versions of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher (currently 5.6.20–7.4), several tooling additions and improvements have been made during the 5.5 cycle.

A large handful of changes were made to address the findings from these tools. Below are some that you need to be aware of.

Automated PHP compatibility scanning

During the WordPress 5.3 cycle, a new job was added to Core’s Travis-CI builds to scan for potential PHP compatibility issues using the PHPCompatibilityWP PHPCS ruleset (see #46152). However, because the scan was reporting a large number of potential issues, it was placed in the allowed_failures list until each issue could be inspected and addressed.

During the 5.5 cycle, each potential issue was examined individually and either fixed, or manually marked as a false-positive.

As of [48046], the job performing a PHP compatibility scan has been removed from the allowed_failures list. 🎉

Now that this scan is not allowed to produce errors or warnings, potential PHP incompatibilities can be flagged and inspected immediately after being committed, ensuring they are never released to the world in WordPress.

In the future when the versions of PHP supported by WordPress change (in either direction), the configuration file can easily be adjusted to detect potential problems within the new range of supported versions.

For more information, see the related ticketticket Created for both bug reports and feature development on the bug tracker. on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. (#49922).

Deprecated: wp_unregister_GLOBALS()

The register_globals directive in PHP was deprecated in version 5.3 and removed entirely in 5.4. Because the first line of the function calls ini_get() (which returns false if the directive is not recognized), this function will always return early making it unnecessary.

The wp_unregister_GLOBALS() function is deprecated as of WordPress 5.5.

For more information, see the related ticket on Trac (#49938).

Deprecated: $HTTP_RAW_POST_DATA

The $HTTP_RAW_POST_DATA global variable was deprecated in PHP 5.6.0 and removed completely in PHP 7.0.0. Because of this, developers should not be relying the presence or accuracy of this variable. However, a search of the plugin directory for this variable still yields ~1,500 results. Although some of these matches are flagging $HTTP_RAW_POST_DATA within comments or in compatibility shims, developers should audit their code to remove this variable whenever possible.

Because PHP 5.6 is still supported and this variable is present in a large number of plugins, it will not be completely removed in WordPress 5.5. However, it will be removed from CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. when the supported versions of PHP is changed to PHP >= 7.0.

The following is the recommended replacement:

$var = file_get_contents( 'php://input' );

A few occurrences of this variable that did not affect the outcome of the code have been removed in 5.5. However, there are 2 instances that will remain because they were deemed particularly risky to remove before communicating the bad practice to the community.

  • xmplrpc.php (source)
  • wp-includes/rest-api/class-wp-rest-server.php (source)

For more information, refer to the related ticket on Trac (#49810).

Spread operator usage in the IXR library

In WordPress 5.3, the PHP spread operator was introduced throughout the code base. There are several benefits to utilizing the spread operator in addition to code modernization:

“Using the spread operator allowed for simplifying the code and improves performance – both in speed as well as memory use -, especially as it has been introduced in a number of functions which are used a multitude of times during every single pageload…”

WP 5.3: Introducing the spread operator by @jrf

The IXR library bundled with Core (now treated as an “adopted” library) powers XML-RPC related functionality in WordPress.

All func_get_args() calls within the IXR library’s code have now been updated to utilize the spread operator.

For more information, refer to the Trac ticket (#48267), the WP 5.3: Introducing the spread operator dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase., or the Trac ticket that originally introduced the spread operator to Core (#47678).

Installing PHPUnit with Composer

Getting a local environment up and running for contributing to WordPress Core can sometimes be difficult, especially when running the PHPUnit test suite is desired. Different combinations of WordPress and PHP versions require different versions of PHPUnit.

Composer is a tool for dependency management in PHP. When project dependencies are specified, it will manage installing and updating those dependencies for you appropriately.

As of [47881], PHPUnit is now defined as a dev requirement in WordPress Core’s composer.json file.

Running composer install will determine the appropriate version of PHPUnit to install based on the PHP version Composer runs on.

For more information, refer to the Trac ticket (#46815).

Other Build/Test Tool improvements

  • Plugins and themes within src are now ignored when running Core linting locally. This will prevent coding standards violations from being flagged when developing locally using src instead of build (see #49781).
  • Previously, when the lint:php job ran on Travis-CI, the code was formatted using PHPCBF prior to linting. Since running composer format returns an error when changes are made, the linting part would not execute and a report would not be generated. Core will no longer run the formatting command prior to linting the code base for issues (see #49722).
  • 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. ruleset has been updated from version 2.1.1 to 2.3.0. For a full list of changes included in this update, read ruleset’s release notes (see #50258).
  • The recommended version of PHP specified in the readme.html file has been changed from 7.3 to 7.4. This brings the recommendation in line with the recommendations found on WordPress.org (see #50480)

Props @earnjam for review.

#5-5, #build-tools, #dev-notes, #php

Updating the Coding standards for modern PHP

Until May last year, contributions to WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. were bound to PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 5.2 syntax and most plugins and themes stuck to the PHP 5.2 minimum requirement as well.

However, with the change to PHP 5.6 as the minimum PHP version for WordPress Core, new PHP features have become available for use in WP Core and with the outlook of a minimum version of PHP 7.x in the (near) future, even more interesting language features will soon become available for use in WordPress Core, plugins and themes.

With that in mind, we’d like to define coding standards for a number of these constructs and propose to implement automated checking for these in 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. tooling in the near future.

While it may still be a while before some of these features will actually be adopted for use in WordPress Core, defining the coding standards in advance will allow for a consistent code base when they do get adopted and will allow for plugins and themes, which are not necessarily bound to the PHP 5.6 minimum, to safeguard their code consistency when they start using more modern PHP already.

To be honest, none of these proposals are terribly exciting and some may not even seem worth mentioning. Most follow either prior art in WordPress Core or industry standards for the same, but in the spirit of openness, we’d like to verify our take on these before implementing them.

Continue reading

#modernizewp, #codingstandards, #php, #wpcs

PHP Native JSON Extension Now Required

The PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher native 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. extension has been bundled and compiled with PHP by default since 5.2.0 (2006). However, a significant number of PHP installs did not include it. In order to ensure a consistent experience for JSON related functionality in all supported versions of PHP, WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. has historically included a large number of workarounds, functions, and polyfills.

In 2011 (WordPress 3.2), an attempt was made to remove JSON related compatibility code. However, it was discovered that a fair number of distributions were still missing the PHP JSON extension by default, and the removed code was restored to ensure compatibility.

In WordPress 5.2, the minimum version of PHP supported was raised from 5.2.6 to 5.6.20. In the 8 year period since the last attempt was made to encourage use of the PHP native JSON extension, the number of distributions with this extension disabled has significantly decreased.

Because of this, the PHP native JSON extension is now required to run WordPress 5.3 and higher.

To prevent compatibility issues, a site that does not have the PHP native JSON extension enabled will see an error message when attempting to upgrade to WordPress 5.3. The update will be cancelled and the site will remain on the current version (see [46455]). This is to prevent potential compatibility issues on servers running custom PHP configurations.

Here’s a summary of what has changed.

Deprecated

The following functions and classes will remain in the code base, but will trigger a deprecated warning when used (see [46205]):

  • The Services_JSON and Services_JSON_Error classes and all methods
  • The wp-includes/class-json.php file
  • The (private) _wp_json_prepare_data() function

Removed

The following functions, and classes have been removed entirely from the code base (see the [46208] changeset):

  • json_encode() function polyfill
  • json_decode() function polyfill
  • _json_decode_object_helper() function polyfill
  • json_last_error_msg() polyfill
  • JsonSerializable interface polyfill
  • $wp_json global variable
  • JSON_PRETTY_PRINT constant polyfill
  • JSON_ERROR_NONE constant polyfill

Unchanged

The wp_json_encode() function will remain with no intention to deprecate it at this time. This function includes an extra sanity check for JSON encoding data and should still be used as the preferred way to encode data into JSON.

For more information about these changes, check out #47699 on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and the relevant changesets ([46205], [46206], [46208], [46377], and [46455]).

Props @jrf & @jorbin for peer review.

#5-3, #dev-notes, #php

WP 5.3: Introducing the spread operator

In WordPress 5.3, the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 5.6 spread operator has been introduced to WordPress in a number of places.

Using the spread operator allowed for simplifying the code and improves performance – both in speed as well as memory use -, especially as it has been introduced in a number of functions which are used a multitude of times during every single pageload, such as current_user_can() and add_query_arg().

For full details, see Trac ticket #47678.

Impact on plugins/themes

Most plugins and themes should see no impact of these patches, other than the improved performance.

However, if 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 is one of the limited number of plugins and themes which extends one of the below listed classes and overloads any of the listed methods, you will need to take action.

What to do if your plugin/theme is affected

In nearly all cases, WP 5.3 has added a new parameter to the function signature using the spread operator. This allows for an easy transition as you can adjust the function signature of the method overloading it to do the same.
You may also want to adjust the code within the overloaded method to get the same performance benefits as the parent method.

See the relevant patches linked below for the full details of the change to each method and for inspiration.

Adding the extra argument will allow your plugin/theme to be compatible with both WP 5.3 and older WP versions, though it does raise the minimum PHP requirement for your plugin/theme to PHP 5.6.
Make sure you annotate this in the readme.txt!

In only one case – wpdb::prepare() -, WP 5.3 has changed an existing parameter.
In the exceptional situation that you would be overloading that method, you will need to make a choice whether you want to continue supporting older WP versions or to set the minimum WP version to WP 5.3.
If you set the minimum WP version to WP 5.3, you need to change the function signature of the overloading method to match the new function signature in WP 5.3 and you may also want to simplify some code in your method too.
If you want to continue to support older WP versions, you will need two versions of the class overload and an if/else toggle to load the correct one depending on the WP version being used.
Note: this really only applies to overloaded wpdb::prepare() methods. There is no need to do this if you overload any of the other affected methods.

What will break if I don’t make the change to my plugin/theme

Nothing. The world will keep turning as it did before.

You may get some complaints from end-users that they are seeing PHP warnings about a mismatched function signature in their PHP error logs, but other than that, all should still work as before.

This is not to say that you shouldn’t update your plugins/themes… You should.
It is just that if you don’t have time to do it right away, you don’t need to worry that your plugin/theme will be bringing sites down.

List of affected classes:

List of affected test classes:

#fortheloveofcode, #modernizewp, #5-3, #dev-notes, #php