[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 boonebgorges):

 dlh - Thanks for the good questions. A slightly modified approach is in
 [attachment:34047.2.diff].

 > Every WP_Query instance that hooks into get_term_metadata() would now
 keep calling lazyload_term_meta() during the action, as opposed to just
 the one instance currently. Would that be a performance risk or load
 unrelated meta?

 > You would need the object to remove the action

 The new technique has the method unhook itself after it's been run once.
 No need to do it more than once for a given set of posts. (In fact, if you
 do it more than once, it won't hurt anything - `update_meta_cache()` does
 nothing if it finds that the caches are already primed - but removing the
 filter does reduce CPU cycles a bit, and seems cleaner.)

 >  If I were using get_posts() or filtering the arguments for a new
 WP_Query, then I couldn't affect lazyloading unless I disabled
 update_post_term_cache. But maybe the performance gain is worth it?

 It's hard to imagine a situation where you'd want to disable lazyloading.
 I guess if you were querying for hundreds of posts, but knew that you were
 only going to need the term meta for a small percentage of them, you might
 prefer to prime the termmeta cache only for those terms. As you note, it'd
 still be possible to do this by (a) disabling 'update_post_term_cache'
 (and presumably doing your own version of it) and then (b) running your
 own termmeta cache priming.

 As a rule, I think that unhookability is a pretty powerful argument
 against using object methods as `add_filter()` callbacks. But this case
 seems like an exception to me: we're only using the filter API because of
 a technicality regarding the way that `get_metadata()` works, and IMO
 there are exceedingly few realistic cases where one would want to change
 the behavior. So I don't mind the hooking method being used, despite my
 general distaste for the technique. But maybe I'm missing something.

 > You couldn't call lazyload_term_meta() without mimicking the
 get_term_metadata() filter arguments.

 Because `lazyload_term_meta()` is called by default, you never need to
 call it directly.

 >  Depending on the construction, it also might not be true there are //
 No extra queries. Term cache should already be primed by
 'update_post_term_cache'.

 It'll never be the case that `lazyload_term_meta()` causes extra queries,
 but you're right that the term cache wouldn't be primed if you called the
 method in a different context. I added a note to the documentation to
 clarify this a bit.

 If you (or anyone else) think that the technique is too cute or too
 problematic, I'm not married to it. I just don't really care for passing
 `WP_Query` objects to functions.

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