[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:  kadamwhite
     Type:  enhancement                          |      Status:  reviewing
 Priority:  normal                               |   Milestone:  5.0
Component:  Options, Meta APIs                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-dev-note has-unit-   |     Focuses:  rest-api
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by flixos90):

 Replying to [comment:79 spacedmonkey]:
 I’m sorry, I feel like there was some miscommunication here. Let me
 clarify a bit:

 > 1. Fixed the `$object_id` being passed to the `get_post_type` function.
 > This on is a no brainer and should remain in the patch.

 It absolutely is, I didn’t remove this.

 > 2. Added support for site meta (blog meta) in `get_object_subtype`.
 > @flixos90  I am extremely confused why this would be removed in your
 patch. I worked on blog meta and I know that this check will work.
 > Blog meta has been in a core for months now and releasing this patch
 without support doesn't make any sense to me at all.

 As I mentioned before, adding support for site meta is not as trivial as
 it seems: It needs further thought in terms of how to handle the naming
 blog vs site, and this is a separate issue from general subtype handling,
 which is the focus of #44387. It should definitely be part of 5.0, but it
 needs more thought and should be an iteration.

 > 3. Add sub type to `is_protected_meta`.
 > After a long chat with @rmccue and @kadamwhite about this, we agree for
 the sake of completeness, that this work should be done.
 > Not adding it to protected meta, makes protected meta an outlier. If it
 doesn't go in this patch,
 > it should go in very soon after in another patch.

 Absolutely. There is #44238 to implement this, and it should go into 5.0
 as well. Let’s not overcomplicate this ticket, but rather iterate with the
 other.

 > 4. Removed comment type
 > I want to work on `register_comment_type` but it is massively out of
 scope for this ticket.

 It would be if it was just an extra feature, but we have to consider
 forward-compatibility here. @rmccue argued that not using the existing
 comment types will lock us in in the future because every comment would
 just have a subtype of “comment”, and I agree with it. I also understand
 your argumentation, it was actually why we didn’t initially include it.
 Long story short, let’s discuss this in the meeting this week. We can
 figure it out on Slack much better than with asynchronous communication.

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