[wp-trac] [WordPress Trac] #34047: Split up `wp_lazyload_term_meta()`; check `$check` before lazyloading

[WordPress Trac]

#34047: Split up `wp_lazyload_term_meta()`; check `$check` before lazyloading
-------------------------+--------------------
 Reporter:  dlh          |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  4.4
Component:  Taxonomy     |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+--------------------

Comment (by dlh):

 > It's hard to imagine a situation where you'd want to disable
 lazyloading.

 The only other situation I had in mind is where I knew I didn't need the
 meta at all for my particular query -- rare as that might be, true enough.

 In 34047.2, it still happens that one `get_term_meta()` call is enough to
 fire `get_term_metadata` and prime every existing query's cache that needs
 it. With that in mind, what about stepping back a bit for something like:

 - Add `update_term_meta_cache` to the `$args` array in
 `WP_Query::parse_query()`. If `true`, does the same priming as the other
 patches here.

 - If `update_term_meta_cache` is `true`, require `update_post_term_cache`
 to also be `true`.

 I'm not sure whether the argument would default to `true`. If it did, then
 of course term meta would always be loaded, earlier than they would be on
 the `get_term_metadata` hook.

 But assuming it wouldn't take very long for `get_term_meta()` calls to
 start appearing in the wild, am I following correctly to say the
 difference would be roughly a wash? Is that assumption even a safe one?

 In any case, I think my main motivation for opening this ticket is being
 addressed regardless, so thanks again. I'll be interested to hear from
 others as well and will help how I can from here.

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