[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:  rest-api
-------------------------------------------------+-------------------------

Comment (by jnylen0):

 Some discussion in Slack today:
 https://wordpress.slack.com/archives/C02RQBWTW/p1491423937985603

 The solution I like the best so far is the introduction of a new
 `WP_Object_Type` class (perhaps not the best name).  This class would be a
 very simple pointer to one or more object types for which the meta key
 should be registered:

 {{{#!php
 <?php
 new WP_Object_Type( 'post' )
 new WP_Object_Type( 'post', 'my-cpt-name' )
 new WP_Object_Type( 'term' )
 new WP_Object_Type( 'term', 'post_tag' )
 new WP_Object_Type( 'comment' )
 new WP_Object_Type( 'comment', 'pingback' )
 new WP_Object_Type( 'user' )
 // etc.
 }}}

 Then, `register_meta` could be updated to accept one of these objects as
 its first parameter, filling in the gap in functionality discussed in this
 ticket.

 Another benefit of this approach is that `register_rest_field` could also
 receive the same update.  Currently it's not possible to register a field
 for all post types at once; we could fill in that gap in functionality at
 the same time, as well as unifying the APIs for these two functions.

 It was proposed to make `WP_Object_Type` a base class for `WP_Post_Type`
 and `WP_Taxonomy`.  I disagree with this because the proposed class is
 '''not''' an object type itself, rather it is a '''pointer''' to one '''or
 more''' object types.  Having a `WP_Object_Type` that can represent "all
 post types" is necessary, but it would break this encapsulation.

 To make it clear that this is '''just''' a pointer to an object type,
 rather than a base for the implementation of object types, perhaps a
 better name for this class is `WP_Object_Type_Filter`.

 There's an initial implementation over at
 [attachment:35658.17.diff:ticket:35658 35658.17.diff].  It's basically
 what I had in mind, but I think the constructor should use two different
 parameters (`$general_type`, `$specific_type`) for clarity and
 explicitness.

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