#56513 closed task (blessed) (fixed)
PHP 8.2: silence dynamic properties deprecation notices
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 6.1 | Priority: | normal |
Severity: | normal | Version: | 6.1 |
Component: | General | Keywords: | has-patch php82 commit |
Focuses: | Cc: |
Description
Dynamic (non-explicitly declared) properties are deprecated as of PHP 8.2 and are expected to become a fatal error in PHP 9.0, though this last part is not 100% certain yet.
RFC: https://wiki.php.net/rfc/deprecate_dynamic_properties
We can basically categorize dynamic properties into four base situations:
Situation | Solution | |
---|---|---|
1. | Typo in property name | Fix the typo, either in the property as declared or where the property assignment happens |
2. | Known, named, dynamic property | Declare the property on the (parent) class |
3. | Known use of unknown dynamic properties | Declare the full set of magic methods on a class (preferred) or let the class extend stdClass (discouraged)
|
4. | Unknown use of unknown dynamic properties | Use the #[AllowDynamicProperties] attribute on the (parent) class and/or declare the full set of magic methods on a class and/or let the class extend stdClass
|
Note: the #[AllowDynamicProperties]
attribute is expected to be a temporary solution and it is expected that support for the attribute will be removed from PHP at some point in the future.
Current status
Patches have been created for Trac #56033 to explicitly declare all "known" dynamic properties (type 1 + 2).
A proposal to mitigate the deprecation for the "unknown" dynamic properties (type 3 + 4) via traits is open in Trac #56034.
However, it is clear that more time is needed to action that proposal.
Interim solution
For the time being, I propose to add the #[AllowDynamicProperties]
attribute on all parent classes in the src
directory and classes which extend a class from an external dependency.
This should buy us more time to get a long-term solution in place via #56034.
The main reasons to add the attribute for now, is to silence "noise" in the form of:
- New (duplicate) Trac tickets being opened about the dynamic properties deprecation.
- WP Core tests error-ing out on the deprecation notices when run against PHP 8.2.
- Integration tests for plugins/themes error-ing out on the deprecation notices when run against PHP 8.2.
- Deprecation notices being logged in error logs on servers which have error logging for this turned on (not the default setup for WP).
As an additional advantage, this will allow us to remove the continue-on-error
for PHP 8.2 test runs in the foreseeable future, which will help prevent new PHP 8.2 incompatibilities from being introduced.
There is already a PR open on GitHub for this ticket: https://github.com/WordPress/wordpress-develop/pull/3123
If/when new classes get added to WP in the mean time (before the solution from #56034 is in place), tooling has been created to either update the current patch and/or create additional patches using the same logic as used to create the current patch.
Attachments (3)
Change History (19)
#2
@
2 years ago
There are two approvals on the related pull request (from @costdev and me) so this is commit ready.
#4
@
2 years ago
As suggested in https://core.trac.wordpress.org/ticket/56009#comment:1
Then tickets for a class or group of similar classes to remove the need for allowing dynamic properties, as there are time and resources to do it properly. It also seems the suggested way to start from the PHP community https://stitcher.io/blog/deprecated-dynamic-properties-in-php-82#a-better-alternative
This ticket was mentioned in Slack in #core by sergey. View the logs.
2 years ago
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
2 years ago
#8
@
2 years ago
- Type changed from defect (bug) to task (blessed)
Switching it to a blessed task, as it is actively worked on by experimented people :)
#10
@
2 years ago
Just as a FYI: while the initial patch has been committed, this ticket remains open for the time being to:
- Discuss whether the principle of the patch should also be applied to WordPress native default themes.
- Allow for a follow-up patch for the same to be applied to any new classes being introduced in WP 6.1.
#11
@
2 years ago
- Keywords commit removed
Removing the commit keyword now the initial patch has been committed to move this out of the commit section of the workflow report.
#12
@
2 years ago
- Keywords commit added
I've added two patches to this ticket:
- With an update to the previous patch to add the attribute to class newly introduced in WP 6.1 (since the previous patch was committed).
- An optional patch to also add the attribute to classes from the WP native themes. I'm not sure we should do this, but if it would be decided, we should, at least a patch is available.
I'm adding the commit
keyword to get the "update" patch committed before WP 6.1-RC.
#56511 was marked as a duplicate.