[wp-trac] [WordPress Trac] #38323: Reconsider $object_subtype handling in `register_meta()`

[WordPress Trac]

#38323: Reconsider $object_subtype handling in `register_meta()`
-------------------------------------------------+-------------------------
 Reporter:  flixos90                             |       Owner:
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
Component:  Options, Meta APIs                   |  Review
 Severity:  normal                               |     Version:
 Keywords:  has-patch needs-unit-tests 2nd-      |  Resolution:
  opinion                                        |     Focuses:
-------------------------------------------------+-------------------------
Changes (by flixos90):

 * keywords:  needs-patch => has-patch needs-unit-tests 2nd-opinion


Comment:

 I have worked on a patch that adds `$object_subtype` handling back in (see
 [attachment:38323.diff]). It has of course many similarities to how things
 originally worked, but there are a few significant changes. Some notes
 about the approach:

 * One issue we previously ran into was that we would need to add the
 `$object_subtype` parameter to all the `*_metadata()` functions. The above
 patch introduces a new function `get_object_subtype( $object_type,
 $object_id )` that automatically detects the subtype of an object. The
 function is used in several locations where we have these two parameters
 available in order to not require passing the object subtype.
 * The object subtype in this patch is not a required argument. That makes
 sense as there is meta that needs to be registered for an entire object
 type (think `_thumbnail_id`) and other meta that is specific to a subtype.
 The subtype being optional also makes using several functions easier (when
 using them for "object type-wide" meta). The only significant change this
 brings can be found in `get_registered_metadata()`: When retrieving all
 registered metadata for an object, we need to look at both meta registered
 for its general type and meta registered for its subtype. In the above
 patch the latter takes precedence in case there are meta keys registered
 for both variants (which shouldn't be done, but can be done). We might
 wanna think about a check when registering meta for a subtype that
 prevents addition if the meta is already registered for the overall type -
 let's see.
 * The `$wp_meta_keys` global structure has obviously changed (back to how
 it was before [changeset:38095]) - is that okay in terms of BC? It
 shouldn't be accessed directly by a plugin anyway since there are
 functions available for everything I could imagine someone would wanna do
 with that data.

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