Changes between Initial Version and Version 1 of Ticket #59224
- Timestamp:
- 08/28/2023 03:11:03 PM (3 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #59224
-
Property
Milestone
changed from
Awaiting Review
to6.4
-
Property
Milestone
changed from
-
Ticket #59224 – Description
initial v1 1 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 ).1 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 ). 2 2 3 3 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. … … 5 5 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`). 6 6 7 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 ).7 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 ).