The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in our bug tracker.
After discussion with several coreCoreCore 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.
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:
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.
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 PHPPHPThe 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 SnifferPHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on PHPCS.), the underlying tooling for WPCSWPCSThe 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 sniffsniffA 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 ticketticketCreated 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 pluginPluginA 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 ContributorsCore 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.
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 ContributorsCore 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 PHPPHPThe 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 CoreCoreCore 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 candidateOne 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.
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 bugbugA 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 ticketticketCreated 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.
Give feedback, write a patchpatchA 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).
While most people here will probably mostly know me as a (PHPPHPThe 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 pluginPluginA 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 ?”.
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 loopLoopThe 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:
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:
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.
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 backportbackportA 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.
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.
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.
So… what do you think ? I eagerly await the reactions of you all!
