[wp-trac] [WordPress Trac] #38323: Reconsider $object_subtype handling in `register_meta()`

WordPress Trac noreply at wordpress.org
Mon Jun 11 18:21:05 UTC 2018


#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:69 spacedmonkey]:
 > My worry is about loading the main object in `get_object_subtype`. There
 have been times where I have not loaded meta using a list of ids (from say
 the options table) and haven't run the normal query class, like
 `WP_Query`. For custom migration code, where the whole object is not
 required is an example. This change may have massive performance effects
 on high end users, this change will not be massively sign posted and well
 documented.

 I don't think we should take this into account, for the following reasons:
 * When reading metadata, this only matters if you use the new function
 `get_registered_metadata()`, which is not commonly used by plugins at this
 point. `get_metadata()` (plus the wrappers) stays unaffected.
 * When writing metadata, the function ''is'' called, but at this point you
 are already making DB queries, usually many at the same time (since
 metadata values are always updated one by one). One extra query here
 doesn't do significant harm, furthermore in most cases there won't even be
 the extra query since the current object is usually loaded already.

 > I disagree with the comment about comment types, as core supports
 pingback and trackbacks, which are well known. I also don't understand why
 to limit the functionality? You are already loading the comment.

 People know that pingbacks and trackbacks exist, that's true for sure, but
 people don't commonly know the term "comment type" or what that is. To be
 honest, WordPress core doesn't fully know what it is itself, that's why I
 think we shouldn't include them. The REST API ignores comment types
 completely for that very reason.

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


More information about the wp-trac mailing list