[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:66 spacedmonkey]:

 > I think we should return the comment_types back in as sub type. This is
 how the code currently works in capabilities.php and see is no good reason
 to change it and break any existing filters. There is a big difference
 between a comment, pingback and trackback. That is  value is having that
 as a sub type.

 I generally would agree with this for the sake of BC, but since the REST
 API doesn't consider comment types at all and since it is generally not
 really defined what comment types are, I think we should keep them out for
 now. The vast majority of developers has no idea that comment types are a
 thing (contrary to post types and taxonomies), so I doubt the filter is
 used in that way, also given that it has not been around for a long time
 and been undocumented, as it was an accidental remainder of #35658. There
 is no benefit from supporting comment subtypes at this point.

 > The new filter `$object_subtype = apply_filters(
 "get_object_subtype_{$object_type}", $object_subtype, $object_id );`
 should be moved to the return value and not just be there for the default.
 All subtypes should be filterable. Also, should sites (blogs) meta be in
 this switch statement?

 I agree with this, let's move the filter to work for every return value. I
 have thought about site meta here too, but I'd prefer if we add support
 for that in a follow-up ticket after this is merged.

 > I also have some worries about performance, as every time subtype is
 loaded, it now loads the parent object is it related. If post meta for
 example was loaded, outside of a WP_Query, it would do a single query (if
 the user is not using object caching) to post object for every different
 id. I have just loaded post meta outside of WP_Query, becuase I didnt want
 to overhead of getting the whole object. But now it is loading the whole
 object. I would like to see some profiling data before merge.

 To what functionality exactly are you referring? If it's about getting the
 parent object in `get_object_subtype()`, I don't think that is an issue.
 When a query is used, all objects are already in cache anyway. And when a
 singular result is accessed, this applies as well.

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