[wp-trac] [WordPress Trac] #62061: Prepare for PHP 8.4
WordPress Trac
noreply at wordpress.org
Wed Sep 18 16:26:51 UTC 2024
#62061: Prepare for PHP 8.4
---------------------------------------------+-----------------------------
Reporter: jrf | Owner: (none)
Type: task (blessed) | Status: new
Priority: normal | Milestone: 6.7
Component: General | Version:
Severity: normal | Resolution:
Keywords: php-84 has-patch has-unit-tests | Focuses: php-
| compatibility
---------------------------------------------+-----------------------------
Old description:
> This is a meta ticket to track the efforts to prepare for PHP 8.4.
>
> For PHP 8.0/8.1/8.2/8.3 specific fixes, please refer to the generic WP
> 6.7 PHP 8.x ticket: #59654
>
> Please link patches related to a specific PHP 8.4 related task to the
> appropriate dedicated issue, if there is one (see the links in the
> description below).
>
> Generic/one-off PHP 8.4 related patches can be linked to this ticket.
>
> Previous PHP meta tickets: #59231 (PHP 8.3), #56009 (PHP 8.2)
>
> ----
>
> == PHP 8.4: Important dates
>
> PHP 8.4 is [https://wiki.php.net/todo/php84 expected to be released on
> November 21 2024].
>
> Other note-worthy dates:
> * The first alpha was released on July 4th 2024.
> * Soft Feature freeze started on August 13, 2024.
> * Hard Feature freeze will be in effect from September 26, 2024.
>
> Please note that PHP 8.4 is the first release following the
> [https://wiki.php.net/rfc/release_cycle_update new release cycle policy].
>
> Changes of note:
> * Implementations for accepted RFCs are now formally allowed to still be
> merged during the beta period, even after (soft) feature freeze.
> * Minor improvements which do not require an RFC, such as adding
> constants, parameters, config options, or even small functions or
> methods, are now also allowed to still be merged during the beta period,
> even after (soft) feature freeze.
>
> **Note**:
> The below represents the status per **September 16, 2024** and is based
> on **PHP 8.4-beta5**.
> Even though PHP 8.4 is in feature freeze, these statuses are subject to
> change due to the extended beta period and allowance for small changes
> during the Beta period.
>
> == Readiness of essential tooling
>
> === [https://github.com/composer/composer Composer] ✅
>
> Current status:
> * CI for Composer itself is being run against PHP 8.4 and is passing.
> * Tests pass on PHP 8.4, though there are a few deprecation notices
> coming from an underlying dependency, which Composer uses at an older
> version due to their minimum PHP requirements. Nothing to be concerned
> about though and nothing blocking.
> * PHPCompatibility (bleeding edge): found no significant issues.
> * **Conclusion:**: The only "real" issues I've managed to identify are in
> the test suite of Composer, which has no impact on end-users of Composer.
>
> > **Note about plugins/themes and the `composer/installers` package**:
> >
> > Plugins often use the Composer Installers package to allow Composer to
> install the plugin within the directory layout expected by WordPress.
> > The Composer Installers package is compatible with PHP 8.4 when using
> the 2.x range.
> >
> > Plugins which still require v1.x of the package will need to widen
> their requirements to `^1.0 || ^2.0` to allow the installers to run
> without deprecation notices on PHP 8.4 (and to prevent installation
> conflicts with plugins which haven't widened their requirements yet).
>
> === [https://github.com/sebastianbergmann/phpunit PHPUnit] ✅
>
> Current status:
> * CI for PHPUnit itself is being run against PHP 8.4.
> * Tests pass on PHP 8.4 for all relevant PHPUnit versions.
> * PHPCompatibility (bleeding edge): found no significant issues.
> * WordPress is behind (see #62004) and uses PHPUnit 8 + 9 (while 10 and
> 11 are already out), but that's not problematic for PHP 8.4 compatibility
> as PHPUnit 8 and 9 have "life support", which means they will be made
> compatible with new PHP versions for the time being.
> * **Conclusion**: No known issues in the relevant release for the WP test
> suite (9.6.20).
>
> === [https://github.com/Yoast/PHPUnit-Polyfills PHPUnit Polyfills] ✅
>
> Current status:
> * CI for PHPUnit Polyfills itself is being run against PHP 8.4.
> * Tests pass on PHP 8.4 for all relevant PHPUnit Polyfills versions.
> * PHPCompatibility (bleeding edge): found no issues.
> * WordPress is behind (see #62004) and uses PHPUnit Polyfills 1.x (while
> 2.x and 3.x are available), but that's not problematic for PHP 8.4
> compatibility. The PHPUnit Polyfills package follows the PHPUnit support
> policy, which means that older majors will continue to be supported and
> made compatible with new PHP versions for as long as the PHPUnit versions
> the major supports, are still supported by PHPUnit.
> * **Conclusion**: No known issues in the relevant release for the WP test
> suite (1.1.2).
>
> === [https://github.com/wp-cli/wp-cli WP-CLI] ⚠
>
> Current status:
> * CI for the packages is being run against PHP 8.4 and CI for all
> packages is run daily. Also see: https://wp-cli.org/dashboard/
> * However, it looks like CI isn't set up to fail on PHP deprecations in
> all circumstances, which allows for new issues to be introduced without
> anybody noticing for some of the packages. /cc @schlessera
> * PHPCompatibility (bleeding edge): found a couple of issues. PRs have
> been opened for [https://github.com/wp-cli/php-cli-tools/pull/173 each]
> [https://github.com/wp-cli/wp-cli/pull/5982 of] [https://github.com/wp-
> cli/wp-cli/pull/5981 these] and most are merged by now.
> * A critical in-depth look at the latest test runs showed a number of
> additional PHP compatibility issues, including some related to PHP 8.1
> and 8.3. Again,
> [https://github.com/pulls?q=is%3Apr+author%3Ajrfnl+archived%3Afalse+user
> %3Awp-cli+PHP+8 PRs have been opened for each of these].
> * **Conclusion**: While there are some issues, these should (hopefully)
> be fixed in the next release, which WP will automatically use in the CI
> jobs, once available.
>
> === Other tooling
>
> Other (PHP) tooling doesn't necessarily have to run against PHP 8.4
> (yet), so has not been evaluated.
>
> Having said that, tooling like PHP_CodeSniffer, WordPressCS and
> PHPCompatibility have no known runtime PHP 8.4 issues at this time,
> though it may still be quite a while before full syntax support is
> available for new PHP 8.4 syntaxes.
>
> == Initial DevOps Tasks
>
> Typical tasks which need to be executed to allow WordPress to prepare for
> PHP 8.4:
>
> === [https://github.com/WordPress/wpdev-docker-images Docker]
>
> Add PHP 8.4 to the Docker images. A [https://github.com/WordPress/wpdev-
> docker-images/pull/148 PR for this] was merged on July 26, 2024.
>
> Notes:
> * There is no Docker image with Xdebug 3.4.0 (PHP 8.4 compatible)
> available yet.
> * There is no Imagick release available yet which is compatible with PHP
> 8.3 or 8.4.
>
> 👉🏻 Once either of the above statuses change, the Docker image(s) will
> need further updates.
>
> === GitHub Actions
>
> Add PHP 8.4 to the GitHub Actions `phpunit-tests.yml` configuration.
> [https://github.com/WordPress/wordpress-develop/pull/7379 GH PR #7379]
> (won't pass until other PRs have been merged, see task list below)
>
> Notes:
> - Test failures on PHP 8.4 should not (yet) fail the build, but as the
> actual script to run the tests has been moved, it is currently impossible
> to use `continue-on-error` as that keyword is not supported when calling
> a reusable workflow... /cc @desrosj
> - There is a small project ongoing in the background to change how the
> PHP tests are being run, including significant adjustments to the
> workflows and matrixes. This project does not directly affect this
> ticket, but this ticket does affect that project.
>
>
> == PHP 8.4 deprecations for which WordPress needs to prepare
>
> === [https://wiki.php.net/rfc/deprecate-implicitly-nullable-types
> Deprecate implicitly nullable parameter types]
>
> PHP 8.4 deprecates implicitly nullable parameters, i.e. typed parameters
> with a `null` default value, which are not explicitly declared as
> nullable.
>
> This is a high impact deprecation, with ~880 of the top 2000 Packagist
> packages being affected by this deprecation.
>
> As the use of type declarations is relatively low in the WP codebase,
> this deprecation didn't hit WP that hard. Initial fixes for this
> deprecation were made in #60786, but some new ones have slipped in.
> [https://github.com/WordPress/wordpress-develop/pull/7369 GH PR #7369]
>
> This deprecation also affected Requests (fixed in v2.0.11), Sodium Compat
> (fixed in 1.21.x) and SimplePie (PR open).
>
> > The typical fix for this deprecation is to make the typed parameter
> explicitly nullable. As WP has dropped support for PHP < 7.2, this is a
> viable solution for WP, but it may not be a viable path for affected
> plugin/themes.
> >
> > When a plugin/theme still supports PHP < 7.1, they will need to apply a
> different solution. Which solution will need to be evaluated on a case-
> by-case basis.
> >
> > Some examples of potential solutions:
> > - If the type declaration is an `array` or scalar type declaration,
> make the default value comply with the expected type.
> > - If the type declaration is class/interface name based, drop the type
> declaration in favour of doing in-function type checking. Mind: for non-
> global functions, non-private or non-final methods, this is a breaking
> change (signature change which will cause a fatal error for overloaded
> non-final, non-private methods).
> > - In some cases, dropping the default value and making the parameter
> required may also be a solution, though again, this could be a breaking
> change.
> > - Raise the minimum supported PHP version to PHP 7.1 and use the
> nullable operator.
> > - etc
>
> ''PHPCompatibility (`develop`) can detect code affected by this
> deprecation.''
>
> === [https://wiki.php.net/rfc/deprecations_php_8_4 Generic deprecations
> for PHP 8.4]
>
> The PHP 8.4 Deprecations RFC was **''huge''** with a whopping 26
> proposals which went to vote, of which 22 passed.
>
> Based on initial (bleeding edge) PHPCompatibility scans + the tests, WP
> will be affected by a number of these deprecations.
>
> I'm going to selectively highlight those deprecations which are most
> relevant in the context of WordPress.
> For full information, please have a read through the RFC itself.
>
> ==== `xml_set_object()` and `xml_set_*_handler()` with string method
> names
>
> The XML Parser extension still supports a quite dated mechanism for
> method based callbacks, where the object is first set via
> `xml_set_object()` and the callbacks are then set by passing only the
> name of the method to the relevant parameters on any of the
> `xml_set_*_handler()` functions.
> {{{#!php
> <?php
> xml_set_object( $parser, $my_obj );
> xml_set_character_data_handler( $parser, 'method_name_on_my_obj' );
> }}}
>
> Passing proper callables to the `xml_set_*_handler()` functions has been
> supported for a long time and is cross-version compatible. So the above
> code is 100% equivalent to:
> {{{#!php
> <?php
> xml_set_character_data_handler( $parser, [$my_obj,
> 'method_name_on_my_obj'] );
> }}}
>
> The mechanism of setting the callbacks with `xml_set_object()` has now
> been deprecated as of PHP 8.4, in favour of passing proper callables to
> the `xml_set_*_handler()` functions. This is also means that calling the
> `xml_set_object()` function is deprecated as well.
>
> This deprecation affects WordPress in a number of places. Patches for
> these issues are available. [https://github.com/WordPress/wordpress-
> develop/pull/7370 GH PR #7370], [https://github.com/WordPress/wordpress-
> develop/pull/7371 GH PR #7371], [https://github.com/WordPress/wordpress-
> develop/pull/7372 GH PR #7372], [https://github.com/WordPress/wordpress-
> develop/pull/7373 GH PR #7373]
>
> ''PHPCompatibility (`develop`) can detect code affected by this
> deprecation.''
>
> ==== Deprecate passing E_USER_ERROR to trigger_error()
>
> PHP 8.4 deprecates passing `E_USER_ERROR` to `trigger_error()`, with the
> recommendation being to replace these type of calls with either throwing
> an `Exception` or an `exit` statement.
>
> WP has its own `wp_trigger_error()` function, which under the hood calls
> `trigger_error()`. If passed `E_USER_ERROR` as the `$error_level`, this
> will hit the PHP 8.4 deprecation.
>
> As a general rule of thumb, I recommend using exceptions to fix this type
> of deprecation, if only because it allows the code to remain testable.
>
> There are circumstances in which a hard `exit()` is warranted, but those
> are few and far between.
>
> This deprecation affects WordPress in a number of places, with
> `wp_trigger_error()` being the primary issue.
> Patches for these issues are available. [https://github.com/WordPress
> /wordpress-develop/pull/7375 GH PR #7375], [https://github.com/WordPress
> /wordpress-develop/pull/7376 GH PR #7376], [https://github.com/WordPress
> /wordpress-develop/pull/7377 GH PR #7377]
>
> > Note:
> > For those people tempted to silence this deprecation notice until PHP
> 9.0:
> > This is not a good idea as it will not be PHP 7 - 8 cross-version
> compatible.
> >
> > Prior to PHP 8.0, error silencing would apply to all errors - including
> the error being thrown.
> > As of PHP 8.0, error silencing will no longer apply to fatal errors, so
> would only silence the deprecation notice (intended behaviour).
> > Also see: https://3v4l.org/ghYGk
>
> ''PHPCompatibility (`develop`) can detect code affected by this
> deprecation.''
>
> ==== Deprecation of mysqli_ping() and mysqli::ping()
>
> The `mysqli_ping()` function is deprecated as of PHP 8.4, though, in
> reality, the function wasn't working according to spec anymore since PHP
> 8.2 when the `libmysql` driver was dropped in favour of `libmysqlnd`,
> which was already the default (and recommended) driver since PHP 5.4.
>
> The `mysqli_ping()` method was also not really correctly named as its
> functionality was to reconnect to the database, not just ping.
>
> The alternative is to "manually" ping the database by sending a `DO 1`
> query (the cheapest possible SQL query).
>
> This issue affects the `wpdb` class in a minor way. Patch available.
> [https://github.com/WordPress/wordpress-develop/pull/7374 GH PR #7374]
>
> It is not expected that (properly coded) plugins or themes are affected
> by this change as those should all be using `$wpdb`.
>
> ''PHPCompatibility (`develop`) will be able to detect code affected by
> this deprecation (PR open).''
>
> ==== Deprecate mysqli_refresh() + Deprecate mysqli_kill()
>
> WordPress itself does not use either of these functions and it is not
> expected that (properly coded) plugins or themes are affected by this
> change as those should all be using `$wpdb`.
>
> ''PHPCompatibility (`develop`) will be able to detect code affected by
> this deprecation (PR upcoming).''
>
> ==== Deprecate the second parameter to mysqli_store_result()
>
> WordPress itself does not this function and it is not expected that
> (properly coded) plugins or themes are affected by this change as those
> should all be using `$wpdb`.
>
> ''PHPCompatibility (`develop`) can detect code affected by this
> deprecation.''
>
> ==== Deprecation of unserialize()'s 'S' tag
>
> Even though supported in PHP itself, this tag was never actually in use
> as it is an artifact of the never-released PHP 6.
>
> WordPress' `is_serialized()` function does not take the `S` tag into
> account.
>
> **Conclusion**: nothing to do.
>
> ==== Deprecate proprietary CSV escaping mechanism
>
> The current implementation of this deprecation is not according to the
> specs outlined in the RFC and basically makes the `$escape` parameter in
> the affected functions - `fputcsv()`, `fgetcsv()` and `str_getcsv()` and
> their `SplFileObject` equivalents - a (soft) required parameter.
>
> In the context of WordPress, this affects WP-CLI.
>
> I've [https://github.com/php/php-src/pull/15569#issuecomment-2354447087
> challenged the current implementation] as it doesn't comply with the spec
> outlined in the RFC and **I recommend not fixing any related deprecation
> until the current discussion has reached a conclusion** (or until the
> hard feature freeze comes into effect, whichever comes first).
>
> ''PHPCompatibility (`develop`) will likely be able to detect code
> affected by this deprecation, but won't until the final implementation is
> settled on.''
>
> ==== Remove E_STRICT error level and deprecate E_STRICT constant
>
> While this proposal has been voted in, the PR to make the actual change
> in PHP looks to have stalled and it is uncertain whether this deprecation
> will take effect in PHP 8.4.
>
> **I recommend not taking any action on this deprecation until the change
> has been committed into PHP Core.**
> If and when this happens, there is one usage of the constant in WP Core
> which will need to be handled.
>
> ''PHPCompatibility (`develop`) will be able to detect code affected by
> this deprecation once it lands in PHP Core.''
>
> ==== Deprecate returning non-string values from a user output handler +
> Deprecate producing output in a user output handler
>
> While both these proposals have been voted in, at this time, no PR to
> make the actual change in PHP Core has been opened yet. This makes it
> exceedingly unlikely that these changes will take effect in PHP 8.4.
>
> **I recommend not taking any action on this deprecation until the change
> has been committed into PHP** and the real world implementation details
> of the deprecation are known.
>
> > Side-note: as a rule of thumb, it should be considered **''strongly
> discouraged''** to use output buffering in the context of WordPress
> anyway, let alone in combination with a custom output handler, as this
> gets very messy very quickly once output buffers are stacked and
> plugins/Core are retrieving a different output buffer than the one they
> expect.
> >
> > For a more detailed explanation about this, see
> [https://github.com/WordPress/WordPress-Coding-Standards/issues/1422 WPCS
> #1422].
>
> ''PHPCompatibility (`develop`) may be able to detect code affected by
> this deprecation, but whether it can or can't won't be clear until the
> final implementation details are known.''
>
> === [https://wiki.php.net/rfc/unbundle_imap_pspell_oci8 Unbundle the
> imap, pspell, and oci8 extensions]
>
> The IMAP, Pspell and OCI8 extensions have been unbundled from PHP and
> moved to PECL, making it less likely for these extensions to be
> installed.
>
> By the looks of it, IMAP is the only extension used in WP and only in the
> PHPMailer dependency, which already has a fall-back in place.
>
> ''PHPCompatibility (`develop`) can detect code affected by this
> deprecation.''
>
>
> == Other PHP 8.4 changes to be aware of
>
> The changes listed below do not directly impact WP Core based on this
> initial investigation, but these may impact the larger eco-system.
>
> These changes are included in this ticket mostly to raise awareness.
>
> === [https://wiki.php.net/rfc/raising_zero_to_power_of_negative_number
> Raising zero to the power of negative number]
>
> This comes down to certain mathematically unsound calculations now
> throwing a deprecation notice.
>
> {{{#!php
> <?php
> //PHP 8.4
> var_dump(0 ** -1); // Deprecated: Zero raised to a negative power is
> deprecated (was float(INF))
> var_dump(0 ** -1.1); //Deprecated: Zero raised to a negative power is
> deprecated (was float(INF))
>
> var_dump(pow(0, -1)); //Deprecated: Zero raised to a negative power is
> deprecated (was float(INF))
> var_dump(pow(0, -1.1)); //Deprecated: Zero raised to a negative power is
> deprecated (was float(INF))
>
> var_dump(1 / 0); //DivisionByZeroError: Division by zero (not changed)
> }}}
>
> To retain the old behaviour, the new PHP 8.4+ `fpow()` function can be
> used.
>
> It does not look like WP is impacted by this deprecation. Still good to
> be aware of, in case bugs get reported which hit these edge cases.
>
> === [https://wiki.php.net/rfc/exit-as-function Exit as a function]
>
> This is largely a semantic change and typically affects the type juggling
> behaviour for `exit` and `die` when passed a parameter between
> parentheses.
> It also means that `exit` and `die` can now be used as a callable,
> respect `strict_types` and can take named arguments.
>
> Take note of this ''unchanged'' behaviour:
> * `exit` and `die` can (still) not be disabled via `disable_functions`
> * `exit` and `die` are still reserved keywords and can not be used for
> function names, whether namespaced or not.
>
> ''PHPCompatibility (`develop`) will be able to detect code affected by
> the changed type juggling behaviour (PR upcoming).''
>
> === [https://wiki.php.net/rfc/http-last-response-headers Add
> http_(get|clear)_last_response_headers() function]
>
> These functions are intended to eventually replace the "magic" function-
> local variable
> [https://www.php.net/manual/en/reserved.variables.httpresponseheader.php
> `$http_response_header`], which is expected to be removed in a future PHP
> version.
>
> === [https://wiki.php.net/rfc/saner-inc-dec-operators Path to Saner
> Increment/Decrement operators]
>
> The second step in this PHP 8.3 RFC - ''"Deprecate using the increment
> operator with non-numeric strings"'' - should have been enacted in PHP
> 8.4, but it looks like this may have been delayed. I've asked for
> clarification on the PHP Internals mailinglist.
>
> === Two deprecations related to PHP native session handling
>
> In the context of WordPress, using PHP native session handling is
> ''strongly discouraged''. Having said that, in the wider eco-system, it
> is known there are plugins/themes out there which persist in using this
> anyway.
>
> PHP native session handling is subject to two separate deprecations in
> PHP 8.4 and developers who use PHP session handling in their code should
> read up on these to evaluate whether these deprecations will impact their
> code.
>
> Ref:
> * https://wiki.php.net/rfc/deprecate-get-post-sessions
> *
> https://wiki.php.net/rfc/deprecations_php_8_4#sessionsid_length_and_sessionsid_bits_per_character
>
> === [https://wiki.php.net/rfc/fix_up_bcmath_number_class Fix up BCMath
> Number Class / Change GMP bool cast behavior]
>
> A GMP object will now behave like an integer when cast.
>
> This means loosy comparisons against a GMP object will behave different,
> in particular for the case where the object value would evaluate to `0`.
>
> {{{#!php
> <?php
> if ( $gmp ) {}
> }}}
>
> == Highlights of PHP 8.4
>
> PHP 8.4, of course, also offers various new features. These can't be used
> by WP until support for PHP < 8.4 has been dropped, though select
> features could be singled-out for polyfilling ahead of time.
>
> The below highlights some of the more interesting new features for future
> use in WordPress.
>
> === [https://wiki.php.net/rfc/deprecated_attribute `#[\Deprecated]`
> Attribute]
>
> An attribute to mark functions and (class-)constants as deprecated and
> throw standardized deprecation notices about these.
>
> This feature is interesting, but not relevant for WordPress until the
> minimum supported PHP version would be PHP 8.4, as polyfilling the
> behaviour for older PHP versions would be quite involved and not worth
> the effort.
>
> === [https://wiki.php.net/rfc/rfc1867-non-post RFC1867 for non-POST HTTP
> verbs]
>
> This RFC introduces a new `request_parse_body()` function to parse
> multipart/form-data received via, for example, `PUT` or `PATCH` HTTP
> requests.
>
> This may be interesting in the future, in particular for the REST API,
> but there is a gotcha: `request_parse_body()` may not be called twice, as
> it destructively consumes `sapi_module.read_post()`.
>
> === [https://wiki.php.net/rfc/array_find array_find, array_find_key,
> array_any and array_all]
>
> PHP 8.4 will come with four new functions ''"which are helper functions
> for common patterns of checking an array for the existence of elements
> matching a specific condition"''.
>
> **It might be worth polyfilling these functions as I suspect that will
> allow for getting rid of some code pattern duplications across the code
> base. Worth looking into for sure.**
>
> === [https://wiki.php.net/rfc/xml_option_parse_huge
> XML_OPTION_PARSE_HUGE]
>
> This solves the problem that parsing large input data (> 10 Mb) is no
> longer allowed by default since libxml2 v 2.7.0.
>
> This might be worth looking into for the WordPress Importer plugin (WXR
> parser) if any users have reported problems with large imports.
>
> === [https://wiki.php.net/rfc/xmlreader_writer_streams Add stream open
> functions to XML{Reader,Writer}]
>
> These improvements will help in resource (memory) management when
> handling large XML files. Unfortunately, it is unlikely that this
> functionality can be polyfilled.
>
> === Various improvements to the DOM extension
>
> These are likely to be very interesting for various parts of WordPress
> once they can be used, but it is unlikely that the functionality can be
> polyfilled.
>
> Refs:
> * https://wiki.php.net/rfc/domdocument_html5_parser
> * https://wiki.php.net/rfc/improve_callbacks_dom_and_xsl
> * https://wiki.php.net/rfc/opt_in_dom_spec_compliance
> * https://wiki.php.net/rfc/dom_additions_84
>
> == Status of External Dependencies
>
> === [https://github.com/wordpress/gutenberg Gutenberg] 🚨
>
> While not strictly an ''external'' dependency, I have scanned Gutenberg
> in the same way as other dependencies as it is being developed in a
> separate repo.
>
> Current status:
> * Tests are **NOT** yet being run against PHP 8.4 (PHP 8.3 is also
> missing). [https://github.com/WordPress/gutenberg/pull/65357 PR to enable
> running against PHP 8.3] is open.
> * Test coverage is **unknown** (not monitored via an online service, not
> locally checkable).
> * PHPCompatibility (bleeding edge): found no issues.
> * Package is using at least one
> [https://github.com/WordPress/gutenberg/pull/65356 outdated PHP
> dependency which needs an update for PHP 8.4 compatibility].
> * Running the tests against PHP 8.4 locally turned out to be impossible
> as the available instructions in the contributing docs don't actually
> work.
> * Trying to get a test run against PHP 8.4 working on GH Actions also
> turned out to be impossible.
> * In other words: **''status unknown''**.
>
> === [https://github.com/JamesHeinrich/getID3 GetID3] ⚠
>
> Current status:
> * Linting is enabled against PHP 8.4. The build passes without finding
> any PHP 8.4 related issues.
> * Test coverage: there are no tests (0%).
> * PHPCompatibility (bleeding edge): found no issues.
> * **Important**: as the project has no test suite, the linting passing on
> PHP 8.4 is only a small comfort and does not provide any real safeguards.
> On the plus side, the project does use PHPStan, which should still be
> able to catch at least some issues.
> * In other words: **''status unknown''**.
> * WordPress is using the latest version (1.9.23), see #59683
> * There have been various bug fix/PHP compatibility related commits since
> the last release, so would be nice if a new release were tagged, but by
> the looks of it, there have been no fixes committed directly related to
> PHP 8.4.
>
> === [https://github.com/PHPMailer/PHPMailer PHPMailer] ✅
>
> PHPMailer uses the IMAP extension, which in PHP 8.4 is moved from PHP to
> PECL.
> The PHPMailer code already contains a fall-back for this (and has for a
> long time).
>
> Current status:
> * Linting and tests are being run against PHP 8.4 and pass.
> * I have a PR lined up to ensure that the tests will also be run without
> IMAP available to ensure the fallback code is tested. This PR will be
> pulled once another open PR has been merged.
> * Test coverage is 76% (non-strict).
> * PHPCompatibility (bleeding edge): found no issues other than the IMAP
> code.
> * WordPress is using the latest version (6.9.1), see #59966
> * There have been various commits since the last release, but nothing
> significant for PHP compatibility.
>
> === [https://github.com/WordPress/Requests Requests] ✅
>
> Current status:
> * There were 2 known PHP 8.4 issues, both of which were already fixed in
> the 2.0.11 release from March 2024.
> * Linting and tests are being run against PHP 8.4.
> * Test coverage is 94% (non-strict).
> * PHPCompatibility (bleeding edge): found no issues.
> * WordPress is using the latest relevant version `2.0.11`, see #60838.
> (Requests 2.0.12 only updated the certificates bundle, while WP uses its
> own)
>
> === [https://github.com/simplepie/simplepie SimplePie] 🚨
>
> Current status:
> * Tests are **NOT** yet being run against PHP 8.4.
> [https://github.com/simplepie/simplepie/pull/876 PR to enable this] is
> open.
> * Test coverage is ~46% for the `1.8` branch (non-strict), ~49% for the
> `master` branch.
> * PHPCompatibility (bleeding edge): found multiple issues. Multiple PRs
> open [https://github.com/simplepie/simplepie/pull/880 #880],
> [https://github.com/simplepie/simplepie/pull/881 #881].
> * WordPress is behind and is still using version `1.5.8`, while the
> latest release is `1.8.0`, see #55604 (ticket is now over two years
> old...).
> * SimplePie 1.8.0 does have some deprecation notices still on PHP 8.4,
> aside from the newly found issues. Some fixes have already been made in
> the `master` branch, but that branch is for 2.0. A
> [https://github.com/simplepie/simplepie/pull/875 PR to backport the PHP
> 8.4 fixes to the 1.8 branch] is open, but will need to be updated with
> the above mentioned additional fixes.
> * All in all, SimplePie is nowhere near ready and it'll be interesting to
> see if a new version gets tagged in time for PHP 8.4 / WP 6.7. That is,
> providing WP actually updates to v 1.8.0 in time to even be able to
> update to the next tag.
>
> Note: There is no expectation that any fixes will be backported to
> branches before the 1.8 branch.
>
> === [https://github.com/paragonie/sodium_compat Sodium Compat] ✅
>
> Current status:
> * Tests are being run against PHP 8.4.
> * Test coverage is 48% (non-strict).
> * PHPCompatibility (bleeding edge): found no issues.
> * No known issues in the last release (1.21.1).
> * WordPress is using the latest version (1.21.1), see #61686.
>
> === [https://github.com/openwall/phpass PHPass] ✅
>
> Current status:
> * Tests are being run against PHP 8.4.
> * Test coverage is 92% (non-strict).
> * PHPCompatibility (bleeding edge): found no issues.
> * No known issues in the current `main` branch, which translates to the
> `0.5.4` version.
> * WordPress is using version `0.5.0`, but the script is a little out of
> sync with upstream, though not in a way that it impacts the running of WP
> on PHP 8.4. Still a good idea to sync with upstream anyway. See #62058.
>
> === [https://github.com/WordPress/wordpress-importer WordPress Importer
> plugin] ⚠
>
> This plugin is used in the test suite.
>
> Current status:
> * Tests are **NOT** (yet) being run against PHP 8.4.
> * Test coverage is ~68% (non-strict).
> * PHPCompatibility (bleeding edge): found one issue.
> [https://github.com/WordPress/wordpress-importer/pull/172 PR to fix this
> has been submitted].
> * The plugin should tag a new version once this PR has been merged.
> * WordPress automatically installs the latest `master` of the plugin when
> the Docker container is installed, so once the above mentioned PR has
> been merged, the related Core automated tests will be able to pass.
>
> > **Important**:
> > Contributors not using Docker for their local dev environment, will
> need to update their copy of the plugin as used for the tests. This
> should be mentioned in a dev-note.
> > Also see: https://make.wordpress.org/core/handbook/contribute/git
> /#unit-tests
>
> == Task list
>
> - [ ] [@jrf] Once current open PR is merged, submit PR to PHPMailer to
> run tests against optimal/minimal dependencies
> - [ ] Update PHPass library, see #62058, patch available.
> - [ ] Review and merge remaining PR(s) for WP-CLI.
> - [ ] Review and merge PR(s) for the WordPress Importer plugin.
> - [ ] Review and commit patches submitted via PRs for WP Core as attached
> to this ticket.
> - [ ] Fixes related to deprecation of implicitly nullable parameters
> - [ ] Fixes related to deprecation of XML Parser custom callables
> - [ ] Fixes related to deprecation of msqli_ping()
> - [ ] Fixes related to deprecation of `trigger_error()` with
> `E_USER_ERROR`
> - [ ] Update to SimplePie 1.8.0, see #55604
> - [ ] Update SimplePie to _next_ release once available (and verify that
> all PHP 8.4 fixes were included).
>
> - [ ] Enable running tests against PHP 8.4 for the WordPress Importer
> plugin
> - [ ] Enable running tests against PHP 8.4 for WordPress Core. This will
> only be possible once both the Importer plugin as well as SimplePie have
> released new versions and WP has updated (for SimplePie). Alternatively,
> we could already turn it on after the WP specific PRs have been merged,
> and temporarily skip the Importer tests and the tests which would fail on
> SimplePie.
New description:
This is a meta ticket to track the efforts to prepare for PHP 8.4.
For PHP 8.0/8.1/8.2/8.3 specific fixes, please refer to the generic WP 6.7
PHP 8.x ticket: #59654
Please link patches related to a specific PHP 8.4 related task to the
appropriate dedicated issue, if there is one (see the links in the
description below).
Generic/one-off PHP 8.4 related patches can be linked to this ticket.
Previous PHP meta tickets: #59231 (PHP 8.3), #56009 (PHP 8.2)
----
== PHP 8.4: Important dates
PHP 8.4 is [https://wiki.php.net/todo/php84 expected to be released on
November 21 2024].
Other note-worthy dates:
* The first alpha was released on July 4th 2024.
* Soft Feature freeze started on August 13, 2024.
* Hard Feature freeze will be in effect from September 26, 2024.
Please note that PHP 8.4 is the first release following the
[https://wiki.php.net/rfc/release_cycle_update new release cycle policy].
Changes of note:
* Implementations for accepted RFCs are now formally allowed to still be
merged during the beta period, even after (soft) feature freeze.
* Minor improvements which do not require an RFC, such as adding
constants, parameters, config options, or even small functions or methods,
are now also allowed to still be merged during the beta period, even after
(soft) feature freeze.
**Note**:
The below represents the status per **September 16, 2024** and is based on
**PHP 8.4-beta5**.
Even though PHP 8.4 is in feature freeze, these statuses are subject to
change due to the extended beta period and allowance for small changes
during the Beta period.
== Readiness of essential tooling
=== [https://github.com/composer/composer Composer] ✅
Current status:
* CI for Composer itself is being run against PHP 8.4 and is passing.
* Tests pass on PHP 8.4, though there are a few deprecation notices coming
from an underlying dependency, which Composer uses at an older version due
to their minimum PHP requirements. Nothing to be concerned about though
and nothing blocking.
* PHPCompatibility (bleeding edge): found no significant issues.
* **Conclusion:**: The only "real" issues I've managed to identify are in
the test suite of Composer, which has no impact on end-users of Composer.
> **Note about plugins/themes and the `composer/installers` package**:
>
> Plugins often use the Composer Installers package to allow Composer to
install the plugin within the directory layout expected by WordPress.
> The Composer Installers package is compatible with PHP 8.4 when using
the 2.x range.
>
> Plugins which still require v1.x of the package will need to widen their
requirements to `^1.0 || ^2.0` to allow the installers to run without
deprecation notices on PHP 8.4 (and to prevent installation conflicts with
plugins which haven't widened their requirements yet).
=== [https://github.com/sebastianbergmann/phpunit PHPUnit] ✅
Current status:
* CI for PHPUnit itself is being run against PHP 8.4.
* Tests pass on PHP 8.4 for all relevant PHPUnit versions.
* PHPCompatibility (bleeding edge): found no significant issues.
* WordPress is behind (see #62004) and uses PHPUnit 8 + 9 (while 10 and 11
are already out), but that's not problematic for PHP 8.4 compatibility as
PHPUnit 8 and 9 have "life support", which means they will be made
compatible with new PHP versions for the time being.
* **Conclusion**: No known issues in the relevant release for the WP test
suite (9.6.20).
=== [https://github.com/Yoast/PHPUnit-Polyfills PHPUnit Polyfills] ✅
Current status:
* CI for PHPUnit Polyfills itself is being run against PHP 8.4.
* Tests pass on PHP 8.4 for all relevant PHPUnit Polyfills versions.
* PHPCompatibility (bleeding edge): found no issues.
* WordPress is behind (see #62004) and uses PHPUnit Polyfills 1.x (while
2.x and 3.x are available), but that's not problematic for PHP 8.4
compatibility. The PHPUnit Polyfills package follows the PHPUnit support
policy, which means that older majors will continue to be supported and
made compatible with new PHP versions for as long as the PHPUnit versions
the major supports, are still supported by PHPUnit.
* **Conclusion**: No known issues in the relevant release for the WP test
suite (1.1.2).
=== [https://github.com/wp-cli/wp-cli WP-CLI] ⚠
Current status:
* CI for the packages is being run against PHP 8.4 and CI for all packages
is run daily. Also see: https://wp-cli.org/dashboard/
* However, it looks like CI isn't set up to fail on PHP deprecations in
all circumstances, which allows for new issues to be introduced without
anybody noticing for some of the packages. /cc @schlessera
* PHPCompatibility (bleeding edge): found a couple of issues. PRs have
been opened for [https://github.com/wp-cli/php-cli-tools/pull/173 each]
[https://github.com/wp-cli/wp-cli/pull/5982 of] [https://github.com/wp-cli
/wp-cli/pull/5981 these] and most are merged by now.
* A critical in-depth look at the latest test runs showed a number of
additional PHP compatibility issues, including some related to PHP 8.1 and
8.3. Again,
[https://github.com/pulls?q=is%3Apr+author%3Ajrfnl+archived%3Afalse+user
%3Awp-cli+PHP+8 PRs have been opened for each of these].
* **Conclusion**: While there are some issues, these should (hopefully) be
fixed in the next release, which WP will automatically use in the CI jobs,
once available.
=== Other tooling
Other (PHP) tooling doesn't necessarily have to run against PHP 8.4 (yet),
so has not been evaluated.
Having said that, tooling like PHP_CodeSniffer, WordPressCS and
PHPCompatibility have no known runtime PHP 8.4 issues at this time, though
it may still be quite a while before full syntax support is available for
new PHP 8.4 syntaxes.
== Initial DevOps Tasks
Typical tasks which need to be executed to allow WordPress to prepare for
PHP 8.4:
=== [https://github.com/WordPress/wpdev-docker-images Docker]
Add PHP 8.4 to the Docker images. A [https://github.com/WordPress/wpdev-
docker-images/pull/148 PR for this] was merged on July 26, 2024.
Notes:
* There is no Docker image with Xdebug 3.4.0 (PHP 8.4 compatible)
available yet.
* There is no Imagick release available yet which is compatible with PHP
8.3 or 8.4.
👉🏻 Once either of the above statuses change, the Docker image(s) will
need further updates.
=== GitHub Actions
Add PHP 8.4 to the GitHub Actions `phpunit-tests.yml` configuration.
[https://github.com/WordPress/wordpress-develop/pull/7379 GH PR #7379]
(won't pass until other PRs have been merged, see task list below)
Notes:
- Test failures on PHP 8.4 should not (yet) fail the build, but as the
actual script to run the tests has been moved, it is currently impossible
to use `continue-on-error` as that keyword is not supported when calling a
reusable workflow... /cc @desrosj
- There is a small project ongoing in the background to change how the PHP
tests are being run, including significant adjustments to the workflows
and matrixes. This project does not directly affect this ticket, but this
ticket does affect that project.
== PHP 8.4 deprecations for which WordPress needs to prepare
=== [https://wiki.php.net/rfc/deprecate-implicitly-nullable-types
Deprecate implicitly nullable parameter types]
PHP 8.4 deprecates implicitly nullable parameters, i.e. typed parameters
with a `null` default value, which are not explicitly declared as
nullable.
This is a high impact deprecation, with ~880 of the top 2000 Packagist
packages being affected by this deprecation.
As the use of type declarations is relatively low in the WP codebase, this
deprecation didn't hit WP that hard. Initial fixes for this deprecation
were made in #60786, but some new ones have slipped in.
[https://github.com/WordPress/wordpress-develop/pull/7369 GH PR #7369]
This deprecation also affected Requests (fixed in v2.0.11), Sodium Compat
(fixed in 1.21.x) and SimplePie (PR open).
> The typical fix for this deprecation is to make the typed parameter
explicitly nullable. As WP has dropped support for PHP < 7.2, this is a
viable solution for WP, but it may not be a viable path for affected
plugin/themes.
>
> When a plugin/theme still supports PHP < 7.1, they will need to apply a
different solution. Which solution will need to be evaluated on a case-by-
case basis.
>
> Some examples of potential solutions:
> - If the type declaration is an `array` or scalar type declaration, make
the default value comply with the expected type.
> - If the type declaration is class/interface name based, drop the type
declaration in favour of doing in-function type checking. Mind: for non-
global functions, non-private or non-final methods, this is a breaking
change (signature change which will cause a fatal error for overloaded
non-final, non-private methods).
> - In some cases, dropping the default value and making the parameter
required may also be a solution, though again, this could be a breaking
change.
> - Raise the minimum supported PHP version to PHP 7.1 and use the
nullable operator.
> - etc
''PHPCompatibility (`develop`) can detect code affected by this
deprecation.''
=== [https://wiki.php.net/rfc/deprecations_php_8_4 Generic deprecations
for PHP 8.4]
The PHP 8.4 Deprecations RFC was **''huge''** with a whopping 26 proposals
which went to vote, of which 22 passed.
Based on initial (bleeding edge) PHPCompatibility scans + the tests, WP
will be affected by a number of these deprecations.
I'm going to selectively highlight those deprecations which are most
relevant in the context of WordPress.
For full information, please have a read through the RFC itself.
==== `xml_set_object()` and `xml_set_*_handler()` with string method names
The XML Parser extension still supports a quite dated mechanism for method
based callbacks, where the object is first set via `xml_set_object()` and
the callbacks are then set by passing only the name of the method to the
relevant parameters on any of the `xml_set_*_handler()` functions.
{{{#!php
<?php
xml_set_object( $parser, $my_obj );
xml_set_character_data_handler( $parser, 'method_name_on_my_obj' );
}}}
Passing proper callables to the `xml_set_*_handler()` functions has been
supported for a long time and is cross-version compatible. So the above
code is 100% equivalent to:
{{{#!php
<?php
xml_set_character_data_handler( $parser, [$my_obj,
'method_name_on_my_obj'] );
}}}
The mechanism of setting the callbacks with `xml_set_object()` has now
been deprecated as of PHP 8.4, in favour of passing proper callables to
the `xml_set_*_handler()` functions. This is also means that calling the
`xml_set_object()` function is deprecated as well.
This deprecation affects WordPress in a number of places. Patches for
these issues are available. [https://github.com/WordPress/wordpress-
develop/pull/7370 GH PR #7370], [https://github.com/WordPress/wordpress-
develop/pull/7371 GH PR #7371], [https://github.com/WordPress/wordpress-
develop/pull/7372 GH PR #7372], [https://github.com/WordPress/wordpress-
develop/pull/7373 GH PR #7373]
''PHPCompatibility (`develop`) can detect code affected by this
deprecation.''
==== Deprecate passing E_USER_ERROR to trigger_error()
PHP 8.4 deprecates passing `E_USER_ERROR` to `trigger_error()`, with the
recommendation being to replace these type of calls with either throwing
an `Exception` or an `exit` statement.
WP has its own `wp_trigger_error()` function, which under the hood calls
`trigger_error()`. If passed `E_USER_ERROR` as the `$error_level`, this
will hit the PHP 8.4 deprecation.
As a general rule of thumb, I recommend using exceptions to fix this type
of deprecation, if only because it allows the code to remain testable.
There are circumstances in which a hard `exit()` is warranted, but those
are few and far between.
This deprecation affects WordPress in a number of places, with
`wp_trigger_error()` being the primary issue.
Patches for these issues are available. [https://github.com/WordPress
/wordpress-develop/pull/7375 GH PR #7375], [https://github.com/WordPress
/wordpress-develop/pull/7376 GH PR #7376], [https://github.com/WordPress
/wordpress-develop/pull/7377 GH PR #7377]
> Note:
> For those people tempted to silence this deprecation notice until PHP
9.0:
> This is not a good idea as it will not be PHP 7 - 8 cross-version
compatible.
>
> Prior to PHP 8.0, error silencing would apply to all errors - including
the error being thrown.
> As of PHP 8.0, error silencing will no longer apply to fatal errors, so
would only silence the deprecation notice (intended behaviour).
> Also see: https://3v4l.org/ghYGk
''PHPCompatibility (`develop`) can detect code affected by this
deprecation.''
==== Deprecation of mysqli_ping() and mysqli::ping()
The `mysqli_ping()` function is deprecated as of PHP 8.4, though, in
reality, the function wasn't working according to spec anymore since PHP
8.2 when the `libmysql` driver was dropped in favour of `libmysqlnd`,
which was already the default (and recommended) driver since PHP 5.4.
The `mysqli_ping()` method was also not really correctly named as its
functionality was to reconnect to the database, not just ping.
The alternative is to "manually" ping the database by sending a `DO 1`
query (the cheapest possible SQL query).
This issue affects the `wpdb` class in a minor way. Patch available.
[https://github.com/WordPress/wordpress-develop/pull/7374 GH PR #7374]
It is not expected that (properly coded) plugins or themes are affected by
this change as those should all be using `$wpdb`.
''PHPCompatibility (`develop`) will be able to detect code affected by
this deprecation (PR open).''
==== Deprecate mysqli_refresh() + Deprecate mysqli_kill()
WordPress itself does not use either of these functions and it is not
expected that (properly coded) plugins or themes are affected by this
change as those should all be using `$wpdb`.
''PHPCompatibility (`develop`) will be able to detect code affected by
this deprecation (PR upcoming).''
==== Deprecate the second parameter to mysqli_store_result()
WordPress itself does not this function and it is not expected that
(properly coded) plugins or themes are affected by this change as those
should all be using `$wpdb`.
''PHPCompatibility (`develop`) can detect code affected by this
deprecation.''
==== Deprecation of unserialize()'s 'S' tag
Even though supported in PHP itself, this tag was never actually in use as
it is an artifact of the never-released PHP 6.
WordPress' `is_serialized()` function does not take the `S` tag into
account.
**Conclusion**: nothing to do.
==== Deprecate proprietary CSV escaping mechanism
The current implementation of this deprecation is not according to the
specs outlined in the RFC and basically makes the `$escape` parameter in
the affected functions - `fputcsv()`, `fgetcsv()` and `str_getcsv()` and
their `SplFileObject` equivalents - a (soft) required parameter.
In the context of WordPress, this affects WP-CLI.
I've [https://github.com/php/php-src/pull/15569#issuecomment-2354447087
challenged the current implementation] as it doesn't comply with the spec
outlined in the RFC and **I recommend not fixing any related deprecation
until the current discussion has reached a conclusion** (or until the hard
feature freeze comes into effect, whichever comes first).
''PHPCompatibility (`develop`) will likely be able to detect code affected
by this deprecation, but won't until the final implementation is settled
on.''
==== Remove E_STRICT error level and deprecate E_STRICT constant
While this proposal has been voted in, the PR to make the actual change in
PHP looks to have stalled and it is uncertain whether this deprecation
will take effect in PHP 8.4.
~~I recommend not taking any action on this deprecation until the change
has been committed into PHP Core.~~
~~If and when this happens, there is one usage of the constant in WP Core
which will need to be handled.~~
[Update 2024-09-18] This change has now been committed to PHP. Patch
available in [https://github.com/WordPress/wordpress-develop/pull/7397 GH
PR #7397]
''PHPCompatibility (`develop`) will be able to detect code affected by
this deprecation once it lands in PHP Core.''
==== Deprecate returning non-string values from a user output handler +
Deprecate producing output in a user output handler
While both these proposals have been voted in, at this time, no PR to make
the actual change in PHP Core has been opened yet. This makes it
exceedingly unlikely that these changes will take effect in PHP 8.4.
**I recommend not taking any action on this deprecation until the change
has been committed into PHP** and the real world implementation details of
the deprecation are known.
> Side-note: as a rule of thumb, it should be considered **''strongly
discouraged''** to use output buffering in the context of WordPress
anyway, let alone in combination with a custom output handler, as this
gets very messy very quickly once output buffers are stacked and
plugins/Core are retrieving a different output buffer than the one they
expect.
>
> For a more detailed explanation about this, see
[https://github.com/WordPress/WordPress-Coding-Standards/issues/1422 WPCS
#1422].
''PHPCompatibility (`develop`) may be able to detect code affected by this
deprecation, but whether it can or can't won't be clear until the final
implementation details are known.''
=== [https://wiki.php.net/rfc/unbundle_imap_pspell_oci8 Unbundle the imap,
pspell, and oci8 extensions]
The IMAP, Pspell and OCI8 extensions have been unbundled from PHP and
moved to PECL, making it less likely for these extensions to be installed.
By the looks of it, IMAP is the only extension used in WP and only in the
PHPMailer dependency, which already has a fall-back in place.
''PHPCompatibility (`develop`) can detect code affected by this
deprecation.''
== Other PHP 8.4 changes to be aware of
The changes listed below do not directly impact WP Core based on this
initial investigation, but these may impact the larger eco-system.
These changes are included in this ticket mostly to raise awareness.
=== [https://wiki.php.net/rfc/raising_zero_to_power_of_negative_number
Raising zero to the power of negative number]
This comes down to certain mathematically unsound calculations now
throwing a deprecation notice.
{{{#!php
<?php
//PHP 8.4
var_dump(0 ** -1); // Deprecated: Zero raised to a negative power is
deprecated (was float(INF))
var_dump(0 ** -1.1); //Deprecated: Zero raised to a negative power is
deprecated (was float(INF))
var_dump(pow(0, -1)); //Deprecated: Zero raised to a negative power is
deprecated (was float(INF))
var_dump(pow(0, -1.1)); //Deprecated: Zero raised to a negative power is
deprecated (was float(INF))
var_dump(1 / 0); //DivisionByZeroError: Division by zero (not changed)
}}}
To retain the old behaviour, the new PHP 8.4+ `fpow()` function can be
used.
It does not look like WP is impacted by this deprecation. Still good to be
aware of, in case bugs get reported which hit these edge cases.
=== [https://wiki.php.net/rfc/exit-as-function Exit as a function]
This is largely a semantic change and typically affects the type juggling
behaviour for `exit` and `die` when passed a parameter between
parentheses.
It also means that `exit` and `die` can now be used as a callable, respect
`strict_types` and can take named arguments.
Take note of this ''unchanged'' behaviour:
* `exit` and `die` can (still) not be disabled via `disable_functions`
* `exit` and `die` are still reserved keywords and can not be used for
function names, whether namespaced or not.
''PHPCompatibility (`develop`) will be able to detect code affected by the
changed type juggling behaviour (PR upcoming).''
=== [https://wiki.php.net/rfc/http-last-response-headers Add
http_(get|clear)_last_response_headers() function]
These functions are intended to eventually replace the "magic" function-
local variable
[https://www.php.net/manual/en/reserved.variables.httpresponseheader.php
`$http_response_header`], which is expected to be removed in a future PHP
version.
=== [https://wiki.php.net/rfc/saner-inc-dec-operators Path to Saner
Increment/Decrement operators]
The second step in this PHP 8.3 RFC - ''"Deprecate using the increment
operator with non-numeric strings"'' - should have been enacted in PHP
8.4, but it looks like this may have been delayed. I've asked for
clarification on the PHP Internals mailinglist.
=== Two deprecations related to PHP native session handling
In the context of WordPress, using PHP native session handling is
''strongly discouraged''. Having said that, in the wider eco-system, it is
known there are plugins/themes out there which persist in using this
anyway.
PHP native session handling is subject to two separate deprecations in PHP
8.4 and developers who use PHP session handling in their code should read
up on these to evaluate whether these deprecations will impact their code.
Ref:
* https://wiki.php.net/rfc/deprecate-get-post-sessions
*
https://wiki.php.net/rfc/deprecations_php_8_4#sessionsid_length_and_sessionsid_bits_per_character
=== [https://wiki.php.net/rfc/fix_up_bcmath_number_class Fix up BCMath
Number Class / Change GMP bool cast behavior]
A GMP object will now behave like an integer when cast.
This means loosy comparisons against a GMP object will behave different,
in particular for the case where the object value would evaluate to `0`.
{{{#!php
<?php
if ( $gmp ) {}
}}}
== Highlights of PHP 8.4
PHP 8.4, of course, also offers various new features. These can't be used
by WP until support for PHP < 8.4 has been dropped, though select features
could be singled-out for polyfilling ahead of time.
The below highlights some of the more interesting new features for future
use in WordPress.
=== [https://wiki.php.net/rfc/deprecated_attribute `#[\Deprecated]`
Attribute]
An attribute to mark functions and (class-)constants as deprecated and
throw standardized deprecation notices about these.
This feature is interesting, but not relevant for WordPress until the
minimum supported PHP version would be PHP 8.4, as polyfilling the
behaviour for older PHP versions would be quite involved and not worth the
effort.
=== [https://wiki.php.net/rfc/rfc1867-non-post RFC1867 for non-POST HTTP
verbs]
This RFC introduces a new `request_parse_body()` function to parse
multipart/form-data received via, for example, `PUT` or `PATCH` HTTP
requests.
This may be interesting in the future, in particular for the REST API, but
there is a gotcha: `request_parse_body()` may not be called twice, as it
destructively consumes `sapi_module.read_post()`.
=== [https://wiki.php.net/rfc/array_find array_find, array_find_key,
array_any and array_all]
PHP 8.4 will come with four new functions ''"which are helper functions
for common patterns of checking an array for the existence of elements
matching a specific condition"''.
**It might be worth polyfilling these functions as I suspect that will
allow for getting rid of some code pattern duplications across the code
base. Worth looking into for sure.**
=== [https://wiki.php.net/rfc/xml_option_parse_huge XML_OPTION_PARSE_HUGE]
This solves the problem that parsing large input data (> 10 Mb) is no
longer allowed by default since libxml2 v 2.7.0.
This might be worth looking into for the WordPress Importer plugin (WXR
parser) if any users have reported problems with large imports.
=== [https://wiki.php.net/rfc/xmlreader_writer_streams Add stream open
functions to XML{Reader,Writer}]
These improvements will help in resource (memory) management when handling
large XML files. Unfortunately, it is unlikely that this functionality can
be polyfilled.
=== Various improvements to the DOM extension
These are likely to be very interesting for various parts of WordPress
once they can be used, but it is unlikely that the functionality can be
polyfilled.
Refs:
* https://wiki.php.net/rfc/domdocument_html5_parser
* https://wiki.php.net/rfc/improve_callbacks_dom_and_xsl
* https://wiki.php.net/rfc/opt_in_dom_spec_compliance
* https://wiki.php.net/rfc/dom_additions_84
== Status of External Dependencies
=== [https://github.com/wordpress/gutenberg Gutenberg] 🚨
While not strictly an ''external'' dependency, I have scanned Gutenberg in
the same way as other dependencies as it is being developed in a separate
repo.
Current status:
* Tests are **NOT** yet being run against PHP 8.4 (PHP 8.3 is also
missing). [https://github.com/WordPress/gutenberg/pull/65357 PR to enable
running against PHP 8.3] is open.
* Test coverage is **unknown** (not monitored via an online service, not
locally checkable).
* PHPCompatibility (bleeding edge): found no issues.
* Package is using at least one
[https://github.com/WordPress/gutenberg/pull/65356 outdated PHP dependency
which needs an update for PHP 8.4 compatibility].
* Running the tests against PHP 8.4 locally turned out to be impossible as
the available instructions in the contributing docs don't actually work.
* Trying to get a test run against PHP 8.4 working on GH Actions also
turned out to be impossible.
* In other words: **''status unknown''**.
=== [https://github.com/JamesHeinrich/getID3 GetID3] ⚠
Current status:
* Linting is enabled against PHP 8.4. The build passes without finding any
PHP 8.4 related issues.
* Test coverage: there are no tests (0%).
* PHPCompatibility (bleeding edge): found no issues.
* **Important**: as the project has no test suite, the linting passing on
PHP 8.4 is only a small comfort and does not provide any real safeguards.
On the plus side, the project does use PHPStan, which should still be able
to catch at least some issues.
* In other words: **''status unknown''**.
* WordPress is using the latest version (1.9.23), see #59683
* There have been various bug fix/PHP compatibility related commits since
the last release, so would be nice if a new release were tagged, but by
the looks of it, there have been no fixes committed directly related to
PHP 8.4.
=== [https://github.com/PHPMailer/PHPMailer PHPMailer] ✅
PHPMailer uses the IMAP extension, which in PHP 8.4 is moved from PHP to
PECL.
The PHPMailer code already contains a fall-back for this (and has for a
long time).
Current status:
* Linting and tests are being run against PHP 8.4 and pass.
* I have a PR lined up to ensure that the tests will also be run without
IMAP available to ensure the fallback code is tested. This PR will be
pulled once another open PR has been merged.
* Test coverage is 76% (non-strict).
* PHPCompatibility (bleeding edge): found no issues other than the IMAP
code.
* WordPress is using the latest version (6.9.1), see #59966
* There have been various commits since the last release, but nothing
significant for PHP compatibility.
=== [https://github.com/WordPress/Requests Requests] ✅
Current status:
* There were 2 known PHP 8.4 issues, both of which were already fixed in
the 2.0.11 release from March 2024.
* Linting and tests are being run against PHP 8.4.
* Test coverage is 94% (non-strict).
* PHPCompatibility (bleeding edge): found no issues.
* WordPress is using the latest relevant version `2.0.11`, see #60838.
(Requests 2.0.12 only updated the certificates bundle, while WP uses its
own)
=== [https://github.com/simplepie/simplepie SimplePie] 🚨
Current status:
* Tests are **NOT** yet being run against PHP 8.4.
[https://github.com/simplepie/simplepie/pull/876 PR to enable this] is
open.
* Test coverage is ~46% for the `1.8` branch (non-strict), ~49% for the
`master` branch.
* PHPCompatibility (bleeding edge): found multiple issues. Multiple PRs
open [https://github.com/simplepie/simplepie/pull/880 #880],
[https://github.com/simplepie/simplepie/pull/881 #881].
* WordPress is behind and is still using version `1.5.8`, while the latest
release is `1.8.0`, see #55604 (ticket is now over two years old...).
* SimplePie 1.8.0 does have some deprecation notices still on PHP 8.4,
aside from the newly found issues. Some fixes have already been made in
the `master` branch, but that branch is for 2.0. A
[https://github.com/simplepie/simplepie/pull/875 PR to backport the PHP
8.4 fixes to the 1.8 branch] is open, but will need to be updated with the
above mentioned additional fixes.
* All in all, SimplePie is nowhere near ready and it'll be interesting to
see if a new version gets tagged in time for PHP 8.4 / WP 6.7. That is,
providing WP actually updates to v 1.8.0 in time to even be able to update
to the next tag.
Note: There is no expectation that any fixes will be backported to
branches before the 1.8 branch.
=== [https://github.com/paragonie/sodium_compat Sodium Compat] ✅
Current status:
* Tests are being run against PHP 8.4.
* Test coverage is 48% (non-strict).
* PHPCompatibility (bleeding edge): found no issues.
* No known issues in the last release (1.21.1).
* WordPress is using the latest version (1.21.1), see #61686.
=== [https://github.com/openwall/phpass PHPass] ✅
Current status:
* Tests are being run against PHP 8.4.
* Test coverage is 92% (non-strict).
* PHPCompatibility (bleeding edge): found no issues.
* No known issues in the current `main` branch, which translates to the
`0.5.4` version.
* WordPress is using version `0.5.0`, but the script is a little out of
sync with upstream, though not in a way that it impacts the running of WP
on PHP 8.4. Still a good idea to sync with upstream anyway. See #62058.
=== [https://github.com/WordPress/wordpress-importer WordPress Importer
plugin] ⚠
This plugin is used in the test suite.
Current status:
* Tests are **NOT** (yet) being run against PHP 8.4.
* Test coverage is ~68% (non-strict).
* PHPCompatibility (bleeding edge): found one issue.
[https://github.com/WordPress/wordpress-importer/pull/172 PR to fix this
has been submitted].
* The plugin should tag a new version once this PR has been merged.
* WordPress automatically installs the latest `master` of the plugin when
the Docker container is installed, so once the above mentioned PR has been
merged, the related Core automated tests will be able to pass.
> **Important**:
> Contributors not using Docker for their local dev environment, will need
to update their copy of the plugin as used for the tests. This should be
mentioned in a dev-note.
> Also see: https://make.wordpress.org/core/handbook/contribute/git/#unit-
tests
== Task list
- [x] [@jrf] Once current open PR is merged, submit PR to PHPMailer to run
tests against optimal/minimal dependencies.
[https://github.com/PHPMailer/PHPMailer/pull/3096 PHPMailer PR#3096]
- [x] Update PHPass library, see #62058, patch available.
- [ ] Review and merge remaining PR(s) for WP-CLI.
- [ ] Review and merge PR(s) for the WordPress Importer plugin.
- [ ] Review and commit patches submitted via PRs for WP Core as attached
to this ticket.
- [x] Fixes related to deprecation of implicitly nullable parameters
- [ ] Fixes related to deprecation of XML Parser custom callables
- [ ] Fixes related to deprecation of msqli_ping()
- [ ] Fixes related to deprecation of `trigger_error()` with
`E_USER_ERROR`
- [ ] Fix related to `E_STRICT`
- [ ] Update to SimplePie 1.8.0, see #55604
- [ ] Update SimplePie to _next_ release once available (and verify that
all PHP 8.4 fixes were included).
- [ ] Enable running tests against PHP 8.4 for the WordPress Importer
plugin
- [ ] Enable running tests against PHP 8.4 for WordPress Core. This will
only be possible once both the Importer plugin as well as SimplePie have
released new versions and WP has updated (for SimplePie). Alternatively,
we could already turn it on after the WP specific PRs have been merged,
and temporarily skip the Importer tests and the tests which would fail on
SimplePie.
--
Comment (by jrf):
Updated with new info about `E_STRICT` and linked the relevant patch in
the ticket.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/62061#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list