[wp-trac] [WordPress Trac] #60787: get_registered_meta_keys() should allow for late registration to improve performance

[WordPress Trac]

#60787: get_registered_meta_keys() should allow for late registration to improve
performance
-------------------------------+------------------------------
 Reporter:  sc0ttkclark        |       Owner:  (none)
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:  has-patch          |     Focuses:  performance
-------------------------------+------------------------------
Changes (by sc0ttkclark):

 * keywords:  has-patch reporter-feedback => has-patch


Comment:

 With the action as proposed, developers don't need to change their code
 except for the action they hook into to register their meta. It's a win-
 win because there's not a brand new API or set of functions. Just a
 ''better time to register them''.

 Use case would be something like this for the many plugins that cover
 custom fields in WP which want to enable their custom fields to be covered
 by the only currently working Block Bindings source on the front AND
 editor in WP 6.5: Post Meta.

 **Current:**

 * Plugin hooks on `init` on every page load
 * During their action, they fetch ALL meta fields for ALL content types
 that need to be registered -- **EVERY PAGE LOAD: Multiple DB requests to
 fetch configs, maybe saved to transient/cache for next page load**
 * Run `register_meta()` for each of the fields
 * ❌ End result: Visitor goes to any page on the front of the site and the
 meta is registered regardless of it being needed by the current context --
 **But if you use the Block Binding API for Custom Fields as shipping in
 6.5 then you have no other choice because it must be registered by render
 time**

 **Proposed:**

 * Plugin hooks on `pre_get_registered_meta_keys` which only gets called in
 the context of `get_registered_meta_keys()` calls
 * During their action, they conditionally fetch ALL meta fields for the
 object type/subtype being requested -- **AS NEEDED: Multiple DB requests
 to fetch configs, maybe saved to transient/cache for next page load**
 * Run `register_meta()` for each of the fields
 * ✅ End result: Visitor goes to any page on the front of the site and the
 meta is not registered unless it is needed by the current context -- **If
 you use the Block Binding API for Custom Fields as shipping in 6.5, your
 meta can be registered in time for this context without any other custom
 code**

 This may be a one-line change for most developers (depending on their
 implementation of course) with a huge benefit overall of reducing DB
 requests, object cache requests, memory usage, or anything else I may be
 forgetting that's involved typically.

 Other areas beyond just Block Bindings API that would be useful to
 increase adoption of `register_meta()` by Custom Fields plugins would be
 Revisions and for showing those fields in the REST API in general.

 I was involved in the original implementation of `register_meta()` and we
 didn't have the wisdom that this would be a problem later, but I
 definitely wish we would have established that action and documented it as
 the official example of how to register meta fields at the time.

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