[wp-trac] [WordPress Trac] #59231: Prepare for PHP 8.3
WordPress Trac
noreply at wordpress.org
Tue Aug 29 13:10:30 UTC 2023
#59231: Prepare for PHP 8.3
--------------------------------------------+------------------------------
Reporter: jrf | Owner: (none)
Type: task (blessed) | Status: new
Priority: normal | Milestone: 6.4
Component: General | Version: trunk
Severity: normal | Resolution:
Keywords: php83 has-patch has-unit-tests | Focuses: php-
| compatibility
--------------------------------------------+------------------------------
Description changed by SergeyBiryukov:
Old description:
> This is a meta ticket to track the efforts to prepare for PHP 8.3.
>
> For PHP 8.0/8.1/8.2 specific fixes, please refer to the generic WP 6.4
> PHP 8.x ticket: #58850
>
> Please link patches related to a specific PHP 8.3 related task to the
> appropriate dedicated issue, if there is one (see the links in the
> description below).
>
> Generic/one-off PHP 8.3 related patches can be linked to this ticket.
>
> ----
>
> == PHP 8.3: Important dates
>
> PHP 8.3 is [https://wiki.php.net/todo/php83 expected to be released on
> November 23 2023].
>
> Other note-worthy dates:
> * The first alpha was released on June 8th 2023.
> * Feature freeze started on July 18, 2023.
>
> **Note**:
>
> The below represents the status per August 28, 2023. As PHP 8.3 is in
> feature freeze, these statuses should be reasonably reliable.
>
> == Readiness of essential tooling
>
> === [https://github.com/composer/composer Composer]
>
> Current status:
> * CI for Composer itself is **NOT** yet being run against PHP 8.3. I've
> opened [https://github.com/composer/composer/pull/11601 a PR] for this.
> * I've ran linting, PHPCompatibility (bleeding edge) and the test suites
> against PHP 8.3 and found no problems for PHP 8.3 though.
> * The only issues I've managed to identify are in the test suite of
> Composer, which has no impact on end-users of Composer.
>
> === [https://github.com/sebastianbergmann/phpunit PHPUnit]
>
> Current status:
> * CI for PHPUnit itself is being run against PHP 8.3.
> * No known issues in the last release supported for the WP test suite
> (9.6.11).
>
> === [https://github.com/Yoast/PHPUnit-Polyfills PHPUnit Polyfills]
>
> Current status:
> * CI for PHPUnit Polyfills itself is being run against PHP 8.3.
> * No known issues in the last release (1.1.0).
>
> === [https://github.com/wp-cli/wp-cli WP-CLI]
>
> Current status:
> * CI for WP-CLI was **NOT** (yet) being run against PHP 8.3. A
> [https://github.com/wp-cli/.github/pull/68 PR to change this has been
> opened and merged].
> * **''Status unknown''**.
>
> === Other tooling
>
> Other (PHP) tooling doesn't necessarily have to run against PHP 8.3
> (yet), so has not been evaluated.
>
> == Initial DevOps Tasks
>
> Typical tasks which need to be executed to allow WordPress to prepare for
> PHP 8.3:
>
> === [https://github.com/WordPress/wpdev-docker-images Docker]
>
> * Add PHP 8.3 to the Docker images. A [https://github.com/WordPress
> /wpdev-docker-images/pull/113 PR for this] was merged on July 26, 2023
>
> === GitHub Actions
>
> * Add PHP 8.3 to the GitHub Actions `phpunit-tests.yml` configuration.
> [https://github.com/WordPress/wordpress-develop/pull/5106 GH PR #5106]
>
> Notes:
> - Test failures on PHP 8.3 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
>
> == PHP 8.3 changes for which WordPress will need to prepare
>
> === [https://wiki.php.net/rfc/deprecations_php_8_3 Generic deprecations
> for PHP 8.3]
>
> Based on initial (bleeding edge) PHPCompatibility scans + the tests, WP
> is not affected by the deprecations which passed from this RFC (not all
> of them did).
>
> ===
> [https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signature
> Deprecation of functions with overloaded signatures]
>
> This RFC only partially affects PHP 8.3. If a replacement is readily
> available already, the deprecation of the overloaded signature takes
> place in PHP 8.3.
> If no replacement was available, the replacement functions are being
> introduced in PHP 8.3 and the actual deprecation of the overloaded
> signature takes place in PHP 8.4.
>
> Based on initial (bleeding edge) PHPCompatibility scans + the tests, WP
> is affected by two of the deprecations in PHP 8.3:
> * `get_class()` and `get_parent_class()` - this is already being tracked
> in #58876, there is a patch available, which IMO is ready for commit.
> * `ReflectionProperty::setValue()` with static properties.
> [https://github.com/WordPress/wordpress-develop/pull/5105 GH PR #5105]
>
> The other deprecations in this RFC do not appear to affect WP Core at
> this time.
>
> There is one - `stream_context_set_option()`, which will impact Requests,
> but only in PHP 8.4 and [https://github.com/WordPress/Requests/pull/822 a
> patch has already been pulled] for this.
>
> === [https://wiki.php.net/rfc/saner-inc-dec-operators Saner
> increment/decrement operators]
>
> To my surprise, I have not found any issues in WP with this change based
> on the tests alone, but I would not be surprised if the odd issue around
> this gets reported over time.
>
> === [https://wiki.php.net/rfc/marking_overriden_methods Marking
> overridden methods]
>
> This is a new feature with limited validation functionality attached. The
> attribute basically allows to mark methods in a (child) class/interface
> which overload a method in a parent class or from an interface, as doing
> so intentionally.
>
> Per the RFC:
> > ... being able to express if a method is intended to override another
> method or implement an interface would make it easier to debug a mistake,
> to refactor and to clean up existing code. Another possible use case is
> to easily detect a possibly breaking change in a parent class that was
> provided by a library without needing to read the changelog in detail or
> missing some item in the list of changes
>
> I'd like to advocate for adding these attributes to WP Core in all the
> relevant places as it:
> * Increases awareness of the method overload for contributors.
> * Can serve as a warning that the method signature should not be touched
> (unless the parent method signature changes).
> * Has no downside as attributes are ignored in older PHP versions and in
> PHP versions where the attribute referenced does not exist.
>
> In the rare case that the attribute, once added, would result in a fatal
> error, that would be fantastic, as that means we have actually found a
> bug in WP before it got into a stable release.
>
> Separate ticket to allow for discussing this proposal in more detail and
> for patches: https://core.trac.wordpress.org/ticket/59232
>
> === [https://wiki.php.net/rfc/unserialize_warn_on_trailing_data Make
> unserialize() emit a warning for trailing bytes]
>
> While based on the current test suite, WP is not ''directly'' affected by
> this, the
> [https://developer.wordpress.org/reference/functions/maybe_unserialize/
> `maybe_unserialize()`] function could still be confronted by data with
> trailing bytes.
>
> However, the call to the PHP native `unserialize()` within
> `maybe_unserialize()` silences all (PHP 8.0+: non-fatal) errors, so this
> new warning will not affect WP or its ecosystem as long as the
> `maybe_unserialize()` function is used.
>
> Having said that, a critical look at `maybe_unserialize()` may be
> warranted as the new warning in PHP is related to security issues
> discovered in other projects, so WP may want to consider rejecting
> unserialization for data throwing this warning.
>
> Also note that there are 7 uses of `unserialize()` in total within WP
> Core, one within `maybe_unserialize()`, but the function is also used in
> 6 other places and 5 of those do not use error silencing.
>
> === [https://wiki.php.net/rfc/improve_unserialize_error_handling Improve
> unserialize() error handling]
>
> This, again, affects the
> [https://developer.wordpress.org/reference/functions/maybe_unserialize/
> `maybe_unserialize()`] function and this time, the code should probably
> be adjusted to handle the new errors which `unserialize()` can now throw.
>
> The change does not affect unserializing valid data, but in the case of
> invalid data, the type of and severity of the notices/warnings/catchable
> exceptions have been changed.
>
> All 7 uses of `unserialize()` in WP Core should be reviewed and for the 6
> uses outside of the `maybe_unserialize()` function, it should be reviewed
> whether they can/should switch to using `maybe_unserialize()` and/or
> whether they should get their own (improved) error handling.
>
> Separate ticket to allow for discussing this and the previously listed
> RFC in more detail and for patches:
> https://core.trac.wordpress.org/ticket/59233
>
> === [https://wiki.php.net/rfc/assert-string-eval-cleanup Deprecate
> remains of string evaluated code assertions]
>
> As WP Core does not use assertions, it is not affected by the changes in
> this RFC.
>
> Plugins/themes may still be affected, though I'd hope none of those would
> use `assert()`.*
>
> * `assert()` is intended for dev-only use. The behaviour of `assert()` is
> heavily affected by ini settings which cannot be changed at runtime,
> which means that end-users may be confronted by unexpected fatal errors
> due to the use of `assert()` if they run on an incorrectly configured
> webhost.
>
> === [https://wiki.php.net/rfc/proper-range-semantics Define proper
> semantics for range() function]
>
> This RFC adds a number of errors and warnings for incorrect use of the
> `range()` function.
>
> WP Core has 8 uses of this function in `src`, 2 in `class-wp-text-diff-
> renderer-table.php` and 6 in various files from external dependencies.
>
> I've visually reviewed each of these and they all look to be okay, though
> a check to safeguard that the WP native uses are covered sufficiently by
> tests would be prudent. [TODO]
>
> === [https://wiki.php.net/rfc/datetime-exceptions More Appropriate
> Date/Time Exceptions]
>
> This RFC reclassifies warnings and errors from the DateTime extension to
> catchable Exceptions when the OO-interface is used (procedural use of the
> DateTime functionality is not affected).
>
> Based on the tests, WP Core is not affected by this and as the DateTime
> use of WP Core is pretty well tested, I'm fairly confident, we'll be
> fine.
>
> === [https://wiki.php.net/rfc/json_validate New json_validate() function]
>
> This function is a high-performance way to validate json prior to
> decoding it. This function cannot be polyfilled without a performance
> hit.
>
> However, due to the potential for using json for Denial-of-Service attack
> vectors (via a HUGE file/stream), I would strongly recommend for WP Core
> to start using this new function in all appropriate places wrapped within
> an `if ( function_exists() ) {}`.
>
> The `json_decode()` function is used 44 times within `src` (excluding
> external dependencies).
>
> We may want to consider introducing a `wp_json_decode()` function to
> ensure the use of `json_validate()` (when available).
> This would then mirror the already existing
> [https://developer.wordpress.org/reference/functions/wp_json_encode/
> `wp_json_encode()`] function.
>
> See: https://core.trac.wordpress.org/ticket/59234
>
> == Status of External Dependencies
>
> === [https://github.com/JamesHeinrich/getID3 GetID3]
>
> Current status:
> * Linting is enabled against PHP 8.3. The build passes without finding
> any PHP 8.3 related issues.
> * **Important**: the project has no test suite, so the linting passing on
> PHP 8.3 is only a small comfort and does not provide any real security.
> * In other words: **''status unknown''**.
> * WordPress is using the latest version (1.9.22), see #56692
>
> === [https://github.com/PHPMailer/PHPMailer PHPMailer]
>
> Current status:
> * Linting and tests are being run against PHP 8.3.
> * No known issues in the last release (6.8.0) (aside from something in
> the PHPMailer test suite, which doesn't affect WP).
> * WordPress is using the latest version, see #57873
>
> === [https://github.com/WordPress/Requests Requests]
>
> Current status:
> * Linting and tests are being run against PHP 8.3.
> * No known issues in the last release (2.0.7) (aside from something in
> the Requests test suite, which doesn't affect WP).
> * WordPress is using the latest relevant version `2.0.6`, see #58079.
> Requests 2.0.7 only updated the certificates bundle, while WP uses its
> own)
>
> === [https://github.com/simplepie/simplepie SimplePie]
>
> Current status:
> * Tests are being run against PHP 8.3.
> * No known issues in the current `master` branch.
> * WordPress is behind and is still using version `1.5.8`, while the
> latest release is `1.6.0`, see #55604
>
> I've done a test run of SimplePie 1.5.8 against PHP 8.3 and based on the
> tests, there are no relevant PHP 8.3 issues known at this moment.
>
> === [https://github.com/paragonie/sodium_compat Sodium Compat]
>
> Current status:
> * A [https://github.com/paragonie/sodium_compat/pull/160 PR has been
> opened] to enable running of the tests against PHP 8.3. The build passes
> without finding any PHP 8.3 related issues.
> * No known issues in the last release (1.20.0).
> * WordPress is using the latest version, see #58224.
>
> === [https://github.com/openwall/phpass PHPass]
>
> Current status:
> * Tests are being run against PHP 8.3.
> * 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.3.
New description:
This is a meta ticket to track the efforts to prepare for PHP 8.3.
For PHP 8.0/8.1/8.2 specific fixes, please refer to the generic WP 6.4 PHP
8.x ticket: #58850
Please link patches related to a specific PHP 8.3 related task to the
appropriate dedicated issue, if there is one (see the links in the
description below).
Generic/one-off PHP 8.3 related patches can be linked to this ticket.
----
== PHP 8.3: Important dates
PHP 8.3 is [https://wiki.php.net/todo/php83 expected to be released on
November 23 2023].
Other note-worthy dates:
* The first alpha was released on June 8th 2023.
* Feature freeze started on July 18, 2023.
**Note**:
The below represents the status per August 28, 2023. As PHP 8.3 is in
feature freeze, these statuses should be reasonably reliable.
== Readiness of essential tooling
=== [https://github.com/composer/composer Composer]
Current status:
* CI for Composer itself is **NOT** yet being run against PHP 8.3. I've
opened [https://github.com/composer/composer/pull/11601 a PR] for this.
* I've ran linting, PHPCompatibility (bleeding edge) and the test suites
against PHP 8.3 and found no problems for PHP 8.3 though.
* The only issues I've managed to identify are in the test suite of
Composer, which has no impact on end-users of Composer.
=== [https://github.com/sebastianbergmann/phpunit PHPUnit]
Current status:
* CI for PHPUnit itself is being run against PHP 8.3.
* No known issues in the last release supported for the WP test suite
(9.6.11).
=== [https://github.com/Yoast/PHPUnit-Polyfills PHPUnit Polyfills]
Current status:
* CI for PHPUnit Polyfills itself is being run against PHP 8.3.
* No known issues in the last release (1.1.0).
=== [https://github.com/wp-cli/wp-cli WP-CLI]
Current status:
* CI for WP-CLI was **NOT** (yet) being run against PHP 8.3. A
[https://github.com/wp-cli/.github/pull/68 PR to change this has been
opened and merged].
* **''Status unknown''**.
=== Other tooling
Other (PHP) tooling doesn't necessarily have to run against PHP 8.3 (yet),
so has not been evaluated.
== Initial DevOps Tasks
Typical tasks which need to be executed to allow WordPress to prepare for
PHP 8.3:
=== [https://github.com/WordPress/wpdev-docker-images Docker]
* Add PHP 8.3 to the Docker images. A [https://github.com/WordPress/wpdev-
docker-images/pull/113 PR for this] was merged on July 26, 2023
=== GitHub Actions
* Add PHP 8.3 to the GitHub Actions `phpunit-tests.yml` configuration.
[https://github.com/WordPress/wordpress-develop/pull/5106 GH PR #5106]
Notes:
- Test failures on PHP 8.3 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
== PHP 8.3 changes for which WordPress will need to prepare
=== [https://wiki.php.net/rfc/deprecations_php_8_3 Generic deprecations
for PHP 8.3]
Based on initial (bleeding edge) PHPCompatibility scans + the tests, WP is
not affected by the deprecations which passed from this RFC (not all of
them did).
===
[https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signature
Deprecation of functions with overloaded signatures]
This RFC only partially affects PHP 8.3. If a replacement is readily
available already, the deprecation of the overloaded signature takes place
in PHP 8.3.
If no replacement was available, the replacement functions are being
introduced in PHP 8.3 and the actual deprecation of the overloaded
signature takes place in PHP 8.4.
Based on initial (bleeding edge) PHPCompatibility scans + the tests, WP is
affected by two of the deprecations in PHP 8.3:
* `get_class()` and `get_parent_class()` - this is already being tracked
in #58876, there is a patch available, which IMO is ready for commit.
* `ReflectionProperty::setValue()` with static properties.
[https://github.com/WordPress/wordpress-develop/pull/5105 GH PR #5105]
The other deprecations in this RFC do not appear to affect WP Core at this
time.
There is one - `stream_context_set_option()`, which will impact Requests,
but only in PHP 8.4 and [https://github.com/WordPress/Requests/pull/822 a
patch has already been pulled] for this.
=== [https://wiki.php.net/rfc/saner-inc-dec-operators Saner
increment/decrement operators]
To my surprise, I have not found any issues in WP with this change based
on the tests alone, but I would not be surprised if the odd issue around
this gets reported over time.
=== [https://wiki.php.net/rfc/marking_overriden_methods Marking overridden
methods]
This is a new feature with limited validation functionality attached. The
attribute basically allows to mark methods in a (child) class/interface
which overload a method in a parent class or from an interface, as doing
so intentionally.
Per the RFC:
> ... being able to express if a method is intended to override another
method or implement an interface would make it easier to debug a mistake,
to refactor and to clean up existing code. Another possible use case is to
easily detect a possibly breaking change in a parent class that was
provided by a library without needing to read the changelog in detail or
missing some item in the list of changes
I'd like to advocate for adding these attributes to WP Core in all the
relevant places as it:
* Increases awareness of the method overload for contributors.
* Can serve as a warning that the method signature should not be touched
(unless the parent method signature changes).
* Has no downside as attributes are ignored in older PHP versions and in
PHP versions where the attribute referenced does not exist.
In the rare case that the attribute, once added, would result in a fatal
error, that would be fantastic, as that means we have actually found a bug
in WP before it got into a stable release.
Separate ticket to allow for discussing this proposal in more detail and
for patches: #59232.
=== [https://wiki.php.net/rfc/unserialize_warn_on_trailing_data Make
unserialize() emit a warning for trailing bytes]
While based on the current test suite, WP is not ''directly'' affected by
this, the
[https://developer.wordpress.org/reference/functions/maybe_unserialize/
`maybe_unserialize()`] function could still be confronted by data with
trailing bytes.
However, the call to the PHP native `unserialize()` within
`maybe_unserialize()` silences all (PHP 8.0+: non-fatal) errors, so this
new warning will not affect WP or its ecosystem as long as the
`maybe_unserialize()` function is used.
Having said that, a critical look at `maybe_unserialize()` may be
warranted as the new warning in PHP is related to security issues
discovered in other projects, so WP may want to consider rejecting
unserialization for data throwing this warning.
Also note that there are 7 uses of `unserialize()` in total within WP
Core, one within `maybe_unserialize()`, but the function is also used in 6
other places and 5 of those do not use error silencing.
=== [https://wiki.php.net/rfc/improve_unserialize_error_handling Improve
unserialize() error handling]
This, again, affects the
[https://developer.wordpress.org/reference/functions/maybe_unserialize/
`maybe_unserialize()`] function and this time, the code should probably be
adjusted to handle the new errors which `unserialize()` can now throw.
The change does not affect unserializing valid data, but in the case of
invalid data, the type of and severity of the notices/warnings/catchable
exceptions have been changed.
All 7 uses of `unserialize()` in WP Core should be reviewed and for the 6
uses outside of the `maybe_unserialize()` function, it should be reviewed
whether they can/should switch to using `maybe_unserialize()` and/or
whether they should get their own (improved) error handling.
Separate ticket to allow for discussing this and the previously listed RFC
in more detail and for patches: #59233.
=== [https://wiki.php.net/rfc/assert-string-eval-cleanup Deprecate remains
of string evaluated code assertions]
As WP Core does not use assertions, it is not affected by the changes in
this RFC.
Plugins/themes may still be affected, though I'd hope none of those would
use `assert()`.*
* `assert()` is intended for dev-only use. The behaviour of `assert()` is
heavily affected by ini settings which cannot be changed at runtime, which
means that end-users may be confronted by unexpected fatal errors due to
the use of `assert()` if they run on an incorrectly configured webhost.
=== [https://wiki.php.net/rfc/proper-range-semantics Define proper
semantics for range() function]
This RFC adds a number of errors and warnings for incorrect use of the
`range()` function.
WP Core has 8 uses of this function in `src`, 2 in `class-wp-text-diff-
renderer-table.php` and 6 in various files from external dependencies.
I've visually reviewed each of these and they all look to be okay, though
a check to safeguard that the WP native uses are covered sufficiently by
tests would be prudent. [TODO]
=== [https://wiki.php.net/rfc/datetime-exceptions More Appropriate
Date/Time Exceptions]
This RFC reclassifies warnings and errors from the DateTime extension to
catchable Exceptions when the OO-interface is used (procedural use of the
DateTime functionality is not affected).
Based on the tests, WP Core is not affected by this and as the DateTime
use of WP Core is pretty well tested, I'm fairly confident, we'll be fine.
=== [https://wiki.php.net/rfc/json_validate New json_validate() function]
This function is a high-performance way to validate json prior to decoding
it. This function cannot be polyfilled without a performance hit.
However, due to the potential for using json for Denial-of-Service attack
vectors (via a HUGE file/stream), I would strongly recommend for WP Core
to start using this new function in all appropriate places wrapped within
an `if ( function_exists() ) {}`.
The `json_decode()` function is used 44 times within `src` (excluding
external dependencies).
We may want to consider introducing a `wp_json_decode()` function to
ensure the use of `json_validate()` (when available).
This would then mirror the already existing
[https://developer.wordpress.org/reference/functions/wp_json_encode/
`wp_json_encode()`] function.
See: #59234
== Status of External Dependencies
=== [https://github.com/JamesHeinrich/getID3 GetID3]
Current status:
* Linting is enabled against PHP 8.3. The build passes without finding any
PHP 8.3 related issues.
* **Important**: the project has no test suite, so the linting passing on
PHP 8.3 is only a small comfort and does not provide any real security.
* In other words: **''status unknown''**.
* WordPress is using the latest version (1.9.22), see #56692
=== [https://github.com/PHPMailer/PHPMailer PHPMailer]
Current status:
* Linting and tests are being run against PHP 8.3.
* No known issues in the last release (6.8.0) (aside from something in the
PHPMailer test suite, which doesn't affect WP).
* WordPress is using the latest version, see #57873
=== [https://github.com/WordPress/Requests Requests]
Current status:
* Linting and tests are being run against PHP 8.3.
* No known issues in the last release (2.0.7) (aside from something in the
Requests test suite, which doesn't affect WP).
* WordPress is using the latest relevant version `2.0.6`, see #58079.
Requests 2.0.7 only updated the certificates bundle, while WP uses its
own)
=== [https://github.com/simplepie/simplepie SimplePie]
Current status:
* Tests are being run against PHP 8.3.
* No known issues in the current `master` branch.
* WordPress is behind and is still using version `1.5.8`, while the latest
release is `1.6.0`, see #55604
I've done a test run of SimplePie 1.5.8 against PHP 8.3 and based on the
tests, there are no relevant PHP 8.3 issues known at this moment.
=== [https://github.com/paragonie/sodium_compat Sodium Compat]
Current status:
* A [https://github.com/paragonie/sodium_compat/pull/160 PR has been
opened] to enable running of the tests against PHP 8.3. The build passes
without finding any PHP 8.3 related issues.
* No known issues in the last release (1.20.0).
* WordPress is using the latest version, see #58224.
=== [https://github.com/openwall/phpass PHPass]
Current status:
* Tests are being run against PHP 8.3.
* 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.3.
--
--
Ticket URL: <https://core.trac.wordpress.org/ticket/59231#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list