WordPress.org

Make WordPress Core

Opened 3 weeks ago

Last modified 42 hours ago

#53635 new task (blessed)

PHP 8.1: various compatibility fixes

Reported by: SergeyBiryukov Owned by:
Milestone: 5.9 Priority: normal
Severity: normal Version:
Component: General Keywords: php81
Focuses: coding-standards Cc:

Description

Previously:

PHP 8.1 release is planned for November 25, 2021. WordPress 5.9 is currently planned for December 2021 and should aim to support PHP 8.1 as much as possible.

This ticket can be used as an "epic", allowing a variety of small patches each fixing a specific failure to be added to and committed against this ticket.

For patches addressing all instances of failures related to one specific PHP 8.1 change across the codebase, separate tickets should still be opened.

For an example of issues/patches with separate tickets, see:

  • #52825 PHP 8.1: MySQLi error reporting value changes
  • #53299 PHP 8.1: Update is_serialized function to accept Enums
  • #53465 PHP 8.1.: the default value of the flags parameter for htmlentities() et all needs to be explicitly set

When opening a separate ticket, please tag it with the php81 keyword, so these can be easily found using this report: https://core.trac.wordpress.org/query?keywords=~php81

Attachments (3)

53635-jsonserialize.patch (847 bytes) - added by jrf 11 days ago.
Fix a "SomeClass::jsonSerialize() should be compatible with JsonSerializable::jsonSerialize(): mixed" error
53635-WP_Hook-iterator-arrayaccess.patch (3.3 KB) - added by jrf 9 days ago.
Fix various "Deprecated: Return type of WP_Hook::[METHODNAME]() should either be compatible with ...., or the #[ReturnTypeWillChange] attribute should be used to temporarily suppress the notice"
53635-WP_Theme-arrayaccess.patch (1.7 KB) - added by jrf 9 days ago.
Fix various "Deprecated: Return type of WP_Theme::[METHODNAME]($offset) should either be compatible with ArrayAccess::[METHODNAME](): type, or the #[ReturnTypeWillChange] attribute should be used to temporarily suppress the notice"

Download all attachments as: .zip

Change History (8)

#1 @SergeyBiryukov
3 weeks ago

In 51396:

Code Modernization: Only check collation in wpdb methods if the query is not empty.

This avoids a deprecation notice on PHP 8.1 caused by passing null instead of a string to ltrim() in wpdb::check_safe_collation(), and maintains the current behaviour.

Follow-up to [30345], [32162], [33455].

See #53635.

@jrf
11 days ago

Fix a "SomeClass::jsonSerialize() should be compatible with JsonSerializable::jsonSerialize(): mixed" error

#2 @jrf
11 days ago

Some context for the patch I just uploaded:

This relates to the Return types for internal methods RFC in PHP 8.1 and in particular, the change made in PHP PR #7051, which adds a mixed return type to the JsonSerializable::jsonSerialize() interface method.

WP only contains one (test) class which implements the JsonSerializable interface and this patch fixes the issue for that class.

Basically, as of PHP 8.1, the jsonSerialize() method in classes which implement the JsonSerializable interface are expected to have a return type declared. The return type should be mixed or a more specific type.
This complies with the Liskov principle of covariance, which allows the return type of a child overloaded method to be more specific than that of the parent.

The problem with this is that:

  1. The mixed return type was only introduced in PHP 8.0 and therefore cannot be used as WP has a minimum PHP version of 5.6.
  2. Return types in general were only introduced in PHP 7.0 and therefore cannot be used as WP has a minimum PHP version of 5.6.

Luckily an attribute has been added to silence the deprecation warning.

While attributes are a PHP 8.0+ feature, due to the choice of the #[] syntax, in PHP < 8.0, attributes will just be ignored and treated as comments, so there is no drawback to using the attribute.

So to fix this, there is basically a choice between two options:

  • Either decouple from the interface. I'd strongly recommend against this as the interface is being implemented for a reason.
  • Or use the attribute, which is what this patch does.

For more details, see the discussion in the upstream PR: https://github.com/php/php-src/pull/7051

@jrf
9 days ago

Fix various "Deprecated: Return type of WP_Hook::[METHODNAME]() should either be compatible with ...., or the #[ReturnTypeWillChange] attribute should be used to temporarily suppress the notice"

@jrf
9 days ago

Fix various "Deprecated: Return type of WP_Theme::[METHODNAME]($offset) should either be compatible with ArrayAccess::[METHODNAME](): type, or the #[ReturnTypeWillChange] attribute should be used to temporarily suppress the notice"

#3 @jrf
9 days ago

Two more patches for the same type of errors as before. The same explanation as outlined in comment #2 applies to these patches as well.

#4 @SergeyBiryukov
42 hours ago

In 51517:

Code Modernization: Fix "JsonSerializable_Object::jsonSerialize() should be compatible with JsonSerializable::jsonSerialize(): mixed" error on PHP 8.1.

This relates to the Return types for internal methods RFC in PHP 8.1 and in particular, the change made in PHP PR #7051, which adds a mixed return type to the JsonSerializable::jsonSerialize() interface method.

WordPress only contains one (test) class which implements the JsonSerializable interface and this commit fixes the issue for that class.

As of PHP 8.1, the jsonSerialize() method in classes which implement the JsonSerializable interface are expected to have a return type declared. The return type should be mixed or a more specific type. This complies with the Liskov principle of covariance, which allows the return type of a child overloaded method to be more specific than that of the parent.

The problem with this is that:

  1. The mixed return type was only introduced in PHP 8.0.
  2. Return types in general were only introduced in PHP 7.0.

WordPress still has a minimum PHP version of 5.6, so adding the return type is not feasible for the time being.

The solution chosen for now is to add an attribute to silence the deprecation warning. While attributes are a PHP 8.0+ feature, due to the choice of the #[] syntax, in PHP < 8.0, attributes will just be ignored and treated as comments, so there is no drawback to using the attribute.

Props jrf.
See #53635.

#5 @hellofromTonya
42 hours ago

Notes from live working session:

  • Check the docs generator to determine if there any issues from the placement of the attribute (which is above the method/function and below the existing DocBlock)

This check needs action before the docs are generated for 5.9.

Note: See TracTickets for help on using tickets.