[wp-trac] [WordPress Trac] #59224: get_pages: duplicate `WP_Query::get_posts` call

[WordPress Trac]

#59224: get_pages: duplicate `WP_Query::get_posts` call
-------------------------------+--------------------------
 Reporter:  david.binda        |       Owner:  (none)
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  6.4
Component:  Posts, Post Types  |     Version:  6.3
 Severity:  normal             |  Resolution:
 Keywords:  has-patch          |     Focuses:  performance
-------------------------------+--------------------------
Changes (by SergeyBiryukov):

 * milestone:  Awaiting Review => 6.4


Old description:

> The internal usage of `WP_Query` in `get_pages` (introduced in r55569 )
> performs the `WP_Query::get_posts()`  call twice ( see
> https://core.trac.wordpress.org/browser/trunk/src/wp-
> includes/post.php?annotate=blame#L6094 ).
>
> When query args are passed to the `WP_Query` constructor, it returns the
> result of the `WP_Query::get_posts` method call (proxied through
> `WP_Query::query`). All the fetched posts are then already present in the
> `WP_Query` object and the correct way to access those is via the
> `WP_Query->posts` property.
>
> In case the `WP_Query::get_posts()` is used, a duplicate SQL query is
> performed, eventually leading to performance downgrade (yet the caching
> inside the `WP_Query` mitigates this to some degree, unless
> `cache_results` query param is set to `true`).
>
> Anyway, I would propose to work with the `WP_Query` inside the
> `get_pages` in the similar way as the code does in the `get_posts`, where
> the query args are passed to the object through the `WP_Query::query`
> method it's return value (the found posts) is being used (see
> https://core.trac.wordpress.org/browser/trunk/src/wp-
> includes/post.php?annotate=blame#L2440 ).

New description:

 The internal usage of `WP_Query` in `get_pages` (introduced in r55569 )
 performs the `WP_Query::get_posts()`  call twice ( see source:tags/6.3/src
 /wp-includes/post.php#L6094 ).

 When query args are passed to the `WP_Query` constructor, it returns the
 result of the `WP_Query::get_posts` method call (proxied through
 `WP_Query::query`). All the fetched posts are then already present in the
 `WP_Query` object and the correct way to access those is via the
 `WP_Query->posts` property.

 In case the `WP_Query::get_posts()` is used, a duplicate SQL query is
 performed, eventually leading to performance downgrade (yet the caching
 inside the `WP_Query` mitigates this to some degree, unless
 `cache_results` query param is set to `true`).

 Anyway, I would propose to work with the `WP_Query` inside the `get_pages`
 in the similar way as the code does in the `get_posts`, where the query
 args are passed to the object through the `WP_Query::query` method it's
 return value (the found posts) is being used (see source:tags/6.3/src/wp-
 includes/post.php#L2440 ).

--

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