[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:  flixos90
     Type:  enhancement                 |      Status:  assigned
 Priority:  normal                      |   Milestone:  5.0
Component:  Options, Meta APIs          |     Version:
 Severity:  normal                      |  Resolution:
 Keywords:  has-patch needs-unit-tests  |     Focuses:  rest-api
----------------------------------------+-----------------------
Changes (by flixos90):

 * keywords:  has-patch needs-unit-tests 2nd-opinion => has-patch needs-
     unit-tests
 * owner:  (none) => flixos90
 * status:  new => assigned


Comment:

 [attachment:38323.5.diff] is a comprehensive update on the patch, which we
 should iterate on from now on. Here is what it does:

 * Add an `object_subtype` argument to the `$args` used in
 `register_meta()`. This can be a post type (in case `$object_type` is
 'post') or a taxonomy (in case `$object_type` is 'term'). For comments and
 users it can be ignored. Aside: While comments have comment types, they
 are used in a completely different way that doesn't apply here (for
 example there is are no REST controllers per comment type, there is just
 one global comments controller).
 * Restructure `$wp_meta_keys` global so that registered meta keys are
 nested under their object type and object subtype. The latter can be an
 empty string for meta keys registered on the entire object type.
 * Add optional `$object_subtype` parameters to all related metadata
 functions that need it. By default it is an empty string in which case
 only meta registered on the entire object type is considered.
 * Introduce a `get_object_subtype()` function which retrieves the subtype
 that needs to be used based on a given object type and object ID of that
 type. For example, if the object type is 'post', the post type is
 returned. A filter `get_object_subtype_{$object_type}` can be used by
 plugin developers who add their own database tables with accompanying
 metadata to define similar behavior for their content.
 * When looking at registered metadata in a context where both object type
 and subtype are available, metadata registered specifically for the
 subtype takes precedence over more general metadata for the entire object
 type. However, such "conflicts" are generally an undesired scenario, so we
 need to educate developers and possibly implement restrictions.
 * Add support for object subtypes to the REST API meta classes.
 * Adjust existing tests that directly look at the `$wp_meta_keys` global
 to account for the restructuring of that object.

 Things that we need to discuss:
 * How do we deal with possible conflicts (i.e. when someone registers a
 meta key for an object type without specifying an object subtype and
 someone else registers the same meta key for the same object type, but
 ''with'' a subtype)?
 * Should we make use of comment types (i.e. allow meta to be registered
 specifically for pingbacks, trackbacks and regular comments) or keep it
 simple and not use subtypes for comments?
 * Should we introduce wrapper functions to make the concept of subtypes
 more obvious (such as `register_post_meta( $post_type, $meta_key, $args
 )`, `register_term_meta( $taxonomy, $meta_key, $args )` etc.) and
 recommend to use those?

 I will publish a post on make.wordpress.org/core/ later this week with a
 few more details on the issue itself and the discussion points that we
 still need to figure out. We will then have a REST API meeting dedicated
 to it next week (on May 3rd).

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