Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #59224


Ignore:
Timestamp:
08/28/2023 03:11:03 PM (9 months ago)
Author:
SergeyBiryukov
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #59224

    • Property Milestone changed from Awaiting Review to 6.4
  • 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 ).
     1The 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 ).
    22
    33When 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.
     
    55In 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`).
    66
    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 ).
     7Anyway, 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 ).