Lazy load post meta

[spacedmonkey]

Trac ticket: https://core.trac.wordpress.org/ticket/57496

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props spacedmonkey, joemcgill, peterwilsoncc.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[joemcgill]

Thanks @spacedmonkey. I haven't tested this, but have left a few questions after reading through the proposed changes.

[joemcgill]

This whole method is a line for line duplication of lazyload_meta_callback() except for this line. Why is the logic different here, and could this be simplified by adding a check for $meta_type to return the $check rather than adding the $object_id to the array of IDs?

[spacedmonkey]

@joemcgill This is the secret sause of this change. Unlike other meta types like, site, comment and term, post meta gets called ALOT. So to stop every call to post meta loading this lazy load queue, this only loads if the queue if an item is in the post meta queue.

For, if I have 10 items of post meta loaded and 5 items in the lazy load queue, if you request an post id in the load meta, you DONT want the queue items to load.

[peterwilsoncc]

@spacedmonkey I think the logic here should be slightly different. If the object ID passed to get_post_meta() is already cached, then it makes sense not to load the queued data. If the object ID is not cached, then a database call will be made and it makes sense to load the queued data.

[spacedmonkey]

@peterwilsoncc that is not how the other meta types work. IDs are put in the queue. If the id is already loaded, when wp_cache_get_multiple, is called, if it is only object is not cache is loaded.

I don't see lots of cases where an id in the queue but also primed. I expect that ids that might be used will be added to the queue, for example attachment meta or post parent meta.

[peterwilsoncc]

@spacedmonkey I realise that is not how it works for other meta data (potentially a bug), but you are proposing that post meta works differently.

However, the code in it's current form will trigger a database query for get_post_meta( $uncached_post_id ) without priming other data in the queue. As the idea of lazy loading meta data is to ride another database query, it seems we should do that here even if the uncached object is not queued.

[spacedmonkey]

@peterwilsoncc So you are saying, we should not have special behavour for post meta, it should work like other meta? That every time get_post_meta is called it should clear the queue? If that is the case, as post meta is called so much, then there is no performance benefit. The queue would be cleared so much, that we might as well not bother.

It is less about saving database queries I guess. It useful in the following use case.

I have loaded 5 posts and there meta. But I have also loaded, all those post parents, ( say for revisions or attachments ). Also add the parents post meta to the queue, as it MAY get used. In cases, where it is, load them all at once, in other cases the items in the queue may never get loaded, saving a database query. There are LOTs of places in core, where post meta is loaded, because it MAY be used a plugin, ( example if you have a filter of the title to change it a value loaded for post meta ). But core itselve is not using this post meta. Once we have a queue, where it says maybe load post meta, we can stop priming post meta in lots of places where it is not required by core, but turning off the priming might effect sites with plugins that except the post meta to be loaded.

[peterwilsoncc]

That every time get_post_meta is called it should clear the queue? If that is the case, as post meta is called so much, then there is no performance benefit. The queue would be cleared so much, that we might as well not bother.

No, this is not what I am saying.

What I am saying is that IF a database query is required then the queue should be cleared. For example:

Cached post meta IDs: 1, 2, 3, 4
Queued post meta IDs: 5, 6, 7, 8

get_post_meta( 1 ) would not clear the queue as it does not require a database call
get_post_meta( 10 ) does require a database call so would use the opportunity to clear the queue and prime the cache for the queued meta data.

[spacedmonkey]

@joemcgill @mukeshpanchal27 mind taking a look at this PR?