[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:  Awaiting Review
Component:  Posts, Post Types  |    Version:  6.3
 Severity:  normal             |   Keywords:  has-patch
  Focuses:  performance        |
-------------------------------+-----------------------------
 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 ).

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