As part of an ongoing effort to improve compatibility across all supported versions of PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 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 ticket Created for both bug reports and feature development on the bug tracker. on Trac 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 Core 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 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 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
You must be logged in to post a comment.