[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
---------------------------+--------------------------

Comment (by lpawlik):

 @boonebgorges Yes, you're right that my patch doesn't distinguish between
 multiple instances of `WP_Query` existing at the same time. I'd like to
 ask you a question as I may not fully understand whole flow here. What
 kind of benefits we have by distinguishing `WP_Query` instances? My point
 is that if we do as you suggest we will still have the same issue as now.
 Let me show you our use scenario:

 - we were going to index all posts in Elasticsearch so we executed
 `WP_Query` in a loop.

 {{{#!php
 $q = new WP_Query( ...args to get group of posts we need... );
 $posts = $q->get_posts();
 foreach( $posts as $post ) {
     $index_data = array(
         'key1' => $post->dummy_value_1,
         'post_content' => apply_filters( 'the_content',
 $post->post_content ),
         ....
         'keyX' => $post->dummy_value_x
     );
     index_post( $index_data );
 }
 }}}

 Let's assume that we have 45000 posts to index so above loop will be
 executed 45k times. Each post content contains `gallery` shortcode which
 executes its own `WP_Query` (not directly but via `get_posts()` function).
 We will have 45k keys in `$this->queries` inside `WP_Lazy_Loader` class
 and each key will contain collection of `WP_Post` items. I am quite sure
 this is more or less the same as we have now but the only difference is
 that `$wp_filter` doesn't contain all data in favour of huge
 `WP_Lazy_Loader` instance. What are possible issues with not
 distinguishing between multiple instances of `WP_Query`? I think we may
 add a little overhead with my approach but on the other hand we may reduce
 memory consumption significantly. As I mentioned above I may not fully
 understand all possible issues this patch can introduce.

 One extra note: we could keep only post `ID` and `post_type` inside
 `WP_Query_Lazy_Load` instead of all `WP_Post` data which would reduce
 memory requirements.

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