Earlier in the 6.7 cycle, @hellofromtonya and @jrf made a number of commits to get the codebase ready for PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 8.4.
Here are a few of the most notable, starting with PR #7376:
Fix trigger_error() with E_USER_ERROR deprecation in wp_trigger_error().
PHP 8.4 deprecates the use ofย trigger_errror()ย withย E_USER_ERRORย as the error level, because this way of creating aย Fatal Error brings its own set of pitfalls (finallyย blocks not executing, destructors not executing). instead, the recommendation is to use an exception or do a hardย exit.
WP has its ownย wp_trigger_error()ย function, which under the hood callsย trigger_error(). If the WP version of the function passesย E_USER_ERRORย as theย $error_level, it too will hit the PHP 8.4 deprecation.
Now, there were basically three options:
- Silence the deprecation until PHP 9.0 and solve this properly then. But that wouldnโt even really buy time, let alone solve the problem. Thatโs because before PHP 8.0, error silencing goes too far, applying to all errors. And starting with PHP 8.0, silencing doesnโt apply to fatal errors.
- Useย
exit($status)ย whenย wp_trigger_error()ย is called withย E_USER_ERROR. But that would make the code untestable. It would also disable handling of these errors with custom error handlers. Neither of those are acceptable outcomes.
- Throw an exception whenย
wp_trigger_error()ย is called withย E_USER_ERROR. This is a fairly elegant solution, and it carries the least BC-breaking impact. There is some chance the error gets caught in aย try-catch, but thatโs not actually a bad thing. Itโs likely to only happen for errors that can be worked aroundโand thatโs actually an unexpected bonus.
This commit implements the third option, which:
- Introduces a newย
WP_Exceptionย class.
- Starts usingย
WP_Exceptionย in theย wp_trigger_error()ย function when theย $error_levelย is set toย E_USER_ERROR.
This change is covered by pre-existing tests, which have been updated to expect the exception instead of a PHP error.
Why not useย WP_Error?
Well, for one, this would lead to completely different behavior (BC).
WP_Errorย doesnโt extendย Exception. So the program would not stop. Instead, it would keep running, which is a much bigger breaking change and carries security risks.ย WP_Errorย also doesnโt natively trigger displaying/logging of the error message, so it would still need anย exitย with the error message, bringing us back to point 2 above.
Introducingย WP_Exceptionย delivers (essentially) the same behavior. It retains the fatal error and error message displaying/logging behaviors. Plus it introduces a base Exception class, which future exception classes can extend over time.
References:
Follow-up toย [56530].
Several other commits, fromย #62061, also help get the codebase ready for 8.4. You can find them after an exhaustive introduction to the changes coming to the new PHP.
Hereโs the list, by GH pull request:
PR #7369 WP_HTML_Processor: fix implicitly nullable parameterย [1] in theย WP_HTML_Processorย class.
PR #7370ย fixes the deprecation of ย xml_set_object()ย for theย TestXMLParserย helper utility.
PR #7371ย fixes the same deprecation for theย IXR_Message::parse()ย method.
PR #7372ย fixes the deprecation for theย AtomParser::parse()ย method.
PR #7373 fixes it for the ย MagpieRSS::__construct()ย method.
PR #7374ย replaces the call to the deprecatedย mysqli_ping()ย with theย DO 1ย query.
PR #7375ย adds a simple test for theย Text_Diff::_check()ย methodโand fixes the bug 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. that test finds!
PR #7377ย adds testing for PR #7376.
PR #7379ย Build/Test Tools: Enable running all the tests on PHP 8.4 once thereโs a stable release of Xdebug 3.4.0.
Propsย @hellofromtonyaย for the commit message that formed the basis of this 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. and to @peterwilsoncc for review and collaboration.
#6-7, #dev-notes, #field-guide
You must be logged in to post a comment.