[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 needs-    |     Focuses:  rest-api
  dev-note                                       |
-------------------------------------------------+-------------------------

Comment (by flixos90):

 Replying to [comment:46 johnjamesjacoby]:
 > I don’t like the “subtype” naming:
 >
 > * it doesn’t exist anywhere in the database schema or code
 > * it conveys there is only 1 additional layer of variation
 > * we would not want subsubsub types
 > * it’s too ambiguous - what a “subtype” means for a post is different
 than a taxonomy and a user and a comment and so on

 While I agree that object subtypes are a rather abstract concept (and thus
 possibly ambiguous), so are object types, and in scope of how WordPress is
 used and has been used for years, basing that abstraction on sub-''types''
 makes sense because a post's / term's behavior for example is
 substantially different based on its type/taxonomy - not based on its
 status, author or other field. In the same way, there are REST API
 controllers per post type/taxonomy. Then, since 'post' itself is an object
 type, that makes a post type an object subtype.

 Object subtypes do not exist in the database schema, but that is a flaw in
 the database schema, given that metadata is largely used based on them
 (metadata for all posts of a specific post type, not for all posts of all
 post types). Furthermore, object subtypes ''do'' already exist in code,
 they are used in `map_meta_cap()`.

 To me the most important point though is that we are introducing wrapper
 functions for `register_meta()` which "clarifies" how to use the function.
 It should be perfectly clear what for example `register_post_meta(
 $post_type, $meta_key, $args )` does. While we are using an abstract
 concept in subtypes (which IMHO is just coherent with how abstract the
 Meta API itself is), the wrapper functions make it obvious how to use it.

 > This is bigger than types or subtypes. This is a meta variation, or a
 meta model, or a meta map. I’m not sure exactly on what it should be
 called, but subtypes locks us into it being a omething it shouldn’t be.

 I don't disagree that we could introduce more possibilities of
 "categorization" in that regard in the future. However, at this point we
 don't want to further overcomplicate solving the immediate problem.

 Replying to [comment:47 Shelob9]:
 > I wanted to cross reference this Gutenberg issue. The schema for block
 attributes supports a default.

 We've already briefly talked about this in a multisite meeting, default
 values for metadata make complete sense. It's great to hear that there's
 already a Gutenberg use-case for #43941. We are planning to tackle this
 ticket once this one here is done, both should be in 5.0.

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