[wp-trac] [WordPress Trac] #35658: Provide additional data for registered meta through register_meta()

[WordPress Trac]

#35658: Provide additional data for registered meta through register_meta()
-------------------------------------------------+-------------------------
 Reporter:  jeremyfelt                           |       Owner:  jeremyfelt
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  4.6
Component:  Options, Meta APIs                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  needs-unit-tests needs-testing has-  |     Focuses:
  patch rest-api                                 |
-------------------------------------------------+-------------------------

Comment (by jeremyfelt):

 Replying to [comment:63 MikeSchinkel]:
 > That worries me because it portends a proliferation of extra optional
 parameters having to be passed around making function signatures more
 complicated and harder to remember.

 Thanks for commenting @MikeSchinkel and @jtsternberg. I can appreciate the
 concern.

 I'd like to avoid the overhead of a `WP_Object_Type` object this time
 around. We only have "registered" subtypes for posts, though #12668 has
 made some things around comment types more friendly. Using this ticket to
 standardize on a new core notation for object type/subtype while trying to
 preserve forward compatibility seems a bit dangerous.

 I don't dislike the syntax of `register_meta( 'post:newsletter', ... )`
 that [attachment:35658.5.diff] would create. It's a new one to core, but
 it's worth thinking about using a similarly formatted string in this
 context.

 After reading through `WP_Object_Type`, I realized that I may want to
 register a meta key to multiple post types. With some work on
 [attachment:35658.4.diff], we could turn that into:

 {{{
 register_meta( 'post', 'issue', array( 'object_subtype' => array(
 'newsletter', 'magazine' ), ... );
 }}}

 By turning the first argument into one that contains both the object and
 object subtype, we would need to register it twice:

 {{{
 register_meta( 'post:newsletter', 'issue', $args );
 register_meta( 'post:magazine', 'issue', $args );
 }}}

 We could turn that first argument into `string|array` and support:

 {{{
 register_meta( array( 'post:magazine', 'post:newsletter' ), 'issue', $args
 );
 }}}

 But that starts to add some complexity to the handling of the first
 argument that I don't think we want to introduce now.

 From a previous [comment:10 comment of mine] that asked a bunch of
 questions:
 > Should a post type (or object subtype) exist before a meta key can be
 registered to it? That could cause confusion depending on the timing of
 registration. It may not hurt anything if registered out of order.

 If we can assume that a post type has always been registered before the
 meta key, then we could accept the object subtype as the first argument
 and then look up it's parent object type. However, this would lock us into
 object subtype uniqueness as comments/posts/terms/users could one day have
 conflicting subtype slugs.

 > So instead please consider creating a combined type in one string in the
 form "{type}:{subtype}", or just "{type}" which defaults "{subtype}" to
 "any".

 I think we should avoid the "any" subtype now and ask for explicit
 registration from developers.

 ---------------------------

 With all that said:

 * **I think we should capture subtype information in `$args`**. It's
 straight-forward and does the least to existing patterns while preserving
 what's possible for the future.
 * I'm okay with developers having to use individual `register_meta()`
 calls for each object/object subtype combination.

 We've had quite a bit of scroll since my [comment:60 request for comments]
 on [https://docs.google.com/document/d
 /13yIH4YU7TwNBOCT0dgjVSJFQ_WtnEVVpkPOI_-Wlneg/edit#heading=h.ail8spb8k7hd
 this document with a draft of dev notes for register_meta], so I'm going
 to drop it in again. :)

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