[wp-trac] [WordPress Trac] #61890: Handle WP_Term dynamic properties for PHP 8.2

[WordPress Trac]

#61890: Handle WP_Term dynamic properties for PHP 8.2
-------------------------------------+-------------------------------------
 Reporter:  hellofromTonya           |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  6.7
Component:  Taxonomy                 |     Version:  4.4
 Severity:  minor                    |  Resolution:
 Keywords:  php82 has-patch has-     |     Focuses:  coding-standards, php-
  unit-tests needs-testing needs-    |  compatibility
  dev-note has-testing-info          |
-------------------------------------+-------------------------------------

Comment (by hellofromTonya):

 With Approach 2 no longer being viable (i.e. to fully support dynamic
 properties), what is / are the possible ways forward to resolve it?

 [https://core.trac.wordpress.org/ticket/61890#Approach1:DeclareCoresknownnamedanddeprecatedynamicproperties
 From this ticket's description]

 **Approach 1: Declare Core's known, named and deprecate dynamic
 properties.**

 Patch: https://github.com/WordPress/wordpress-develop/pull/7224

 Per #56034:
 >Situation: Known, named, dynamic property
 >Resolution: Declare the property on the (parent) class

 This approach proposes to:
 * Soft remove support of dynamic properties by deprecating getting dynamic
 properties.
 * Identify and declare all of Core's known, named dynamic properties on
 the `WP_Term` class.

 Goals:
 * Remove Core's dynamic properties.
 * Alert extenders via deprecation notice and dev note.
 * Extenders to remove their `WP_Term` dynamic properties and replace with
 a different custom handling approach. (Note: need to figure out what to
 recommend to extenders for this migration process.)

 What to recommend to extenders for mitigating the deprecation notices?
 @adrianduffell [comment:25 shared an idea] of recommending extenders use
 term meta.

 **Approach 3: Introduce new classes for each instance where Core is adding
 dynamic properties to extend `WP_Term`**

 @adrianduffell [comment:25 raised this idea]:
 >At this point, the object resembles a `WP_Term`, but has morphed into
 something slightly different. A problem arises in the
 `wp_generate_tag_cloud()` function, which states in its documentation that
 an array of `WP_Term` objects should be passed to it, but actually expects
 the dynamic properties to be present in the object as well. The problem is
 developers won't know from the documentation to add the dynamic properties
 when using `wp_generate_tag_cloud()`. I think it would be better OOP-wise
 to handle the data in a new class, e.g. `WP_Tag`, that explicitly includes
 the extra properties in it's definition along with full documentation
 about them. This way, `wp_generate_tag_cloud()` could clearly document its
 requirement for the additional properties just by stating `WP_Tag` objects
 are passed to it.

 I think the idea is interesting and could/should be extended to each
 instance where Core is adding dynamic properties to extend `WP_Term`.

 Are there instances where extenders are using or expecting these Core
 dynamic properties? If yes, then BC is a concern.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61890#comment:32>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform