[wp-trac] [WordPress Trac] #35816: Add "after_get_posts" action to `WP_Query::get_posts()`

[WordPress Trac]

#35816: Add "after_get_posts" action to `WP_Query::get_posts()`
---------------------------+--------------------------
 Reporter:  stevegrunwell  |       Owner:
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  4.5
Component:  Query          |     Version:  trunk
 Severity:  normal         |  Resolution:
 Keywords:                 |     Focuses:  performance
---------------------------+--------------------------
Changes (by boonebgorges):

 * milestone:  Awaiting Review => 4.5


Comment:

 @stevegrunwell Thanks very much for the detailed request.

 Related: #35454

 A new action here shouldn't be a problem.

 That said, it would be nice to avoid the "catastrophic" consequences to
 begin with. You mention that the overhead is being caused by PHP keeping
 the `WP_Query` objects in memory. Is this conjecture, or is your profiling
 telling you this? I ask because there are a number of potential resource-
 hogs here: `call_user_func()` in `apply_filters()`; excessive object cache
 access due to race conditions (see
 https://core.trac.wordpress.org/ticket/35454#comment:3); etc.

 The ideal solution is to `remove_filter( 'get_term_metadata', array(
 $this, 'lazyload_term_meta' ), 10, 2 );` after the callback takes place
 the first time. As you probably saw in the source code, I noted when the
 lazyload functionality was introduced that it was impossible to
 `remove_filter()` because `_wp_filter_build_unique_id()` was not reliably
 returning unique IDs for similar objects; as a result, calling
 `remove_filter()` in a nested `WP_Query` instance could result in
 lazyloading being disabled for *all* current instances. However, I've been
 doing some more testing, and while I still think it's possible for
 `_wp_filter_build_unique_id()` to behave like this (something I'll open a
 separate ticket about), I think it will very rarely have an effect in this
 case, and it only did during 4.4 development because of the very specific
 kinds of tests I'd written.

 So here's what I'm going to do: I'm going to swap out the
 `updated_term_meta_cache` flags, and replace with `remove_filter()`. This
 ought to fix your immediate issue, since the object will be removed from
 the `$wp_filter` global, and PHP should be able to reclaim the memory
 space. If you don't mind, I'll ask you to run this against your import
 scripts, to verify that it's resolving the issue for you. Then we can talk
 about whether the new action you've suggested still has a use case.

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