[wp-trac] [WordPress Trac] #56992: The Loop displays incorrect data for queries started with `fields => 'id=>parent'`.

[WordPress Trac]

#56992: The Loop displays incorrect data for queries started with `fields =>
'id=>parent'`.
-------------------------------------------------+-------------------------
 Reporter:  peterwilsoncc                        |       Owner:
                                                 |  peterwilsoncc
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  6.8
Component:  Query                                |     Version:  3.1
 Severity:  normal                               |  Resolution:
 Keywords:  dev-feedback has-patch has-unit-     |     Focuses:
  tests                                          |  performance
-------------------------------------------------+-------------------------
Changes (by joemcgill):

 * keywords:  2nd-opinion dev-feedback has-patch has-unit-tests => dev-
     feedback has-patch has-unit-tests


Comment:

 @peterwilsoncc thanks for the ping. I've re-read conversation here and
 tested the reported bug prior to any of the changes that have been
 committed here, just to make sure I understand the issues trying to be
 addressed. Here's my current understanding of the situation:

 The `WP_Query` methods that are used in "the loop", specifically
 `::the_post()` and `::next_post()` and have long assumed that the
 `WP_Query::post` property (when set) and the global $post variable will be
 hydrated with a `WP_Post` object so that template tag functions like
 `get_the_title()`, `get_the_excerpt()`, `get_the_content()`, etc. will
 work as expected.

 When a custom `WP_Query()` is created with `fields=>'all'` or
 `fields=>'ids'` is passed to the loop, then things work as expected, but
 if `fields=>'id=>parent'` is used, then the correct `WP_Post` data does
 not get properly hydrated. I agree that this seems like unexpected
 behavior based on the way these methods are documented. It's possible that
 someone is relying on this undocumented behavior, but my opinion is that
 it is more predictable, and less buggy to ensure that these methods work
 as documented.

 The following unit test can be used, and manipulated to observe this
 issue:

 {{{#!php
 <?php
         /**
          * @group test
          */
         public function test_the_loop_when_querying_post_parents_only() {
                 global $post;

                 $parent = self::factory()->post->create( array(
 'post_type' => 'page' ) );
                 $child  = self::factory()->post->create(
                         array(
                                 'post_type'   => 'page',
                                 'post_parent' => $parent,
                         )
                 );

                 $query = new WP_Query(
                         array(
                                 // Manipulate this arg to see how the
 template tags are affected.
                                 'fields'    => 'id=>parent',
                                 'post_type' => 'page',
                                 'page_id'   => $child,
                         )
                 );

                 $query->the_post();
                 var_dump(
                         array(
                                 'title'   => get_the_title(),
                                 'excerpt' => get_the_excerpt(),
                                 'content' => get_the_content(),
                                 'date'    => get_the_date(),
                         )
                 );

                 $this->assertInstanceOf( 'WP_Post', $post );
         }
 }}}


 As for the performance concerns that @SirLouen has raised, I agree that
 the normal intent of generating a `WP_Query` using `fields='id=>parent'`
 is designed to be a more performant way to query hierarchical
 relationships with posts in order to avoid needing to traverse the entire
 posts table. Even so, if that query is then passed into a loop, users
 should be able to expect that the post data is hydrated with the full post
 data. There are already many places where we have already put in place
 cache priming to ensure that the full data for posts and parent posts are
 loaded efficiently in a single DB query ([https://github.com/WordPress
 /wordpress-develop/blob/1cd5c21c43ccb82165d76e59fc062cb56b5d04d2/src/wp-
 includes/class-wp-query.php#L3259-L3279 example 1],
 [https://github.com/WordPress/wordpress-
 develop/blob/1cd5c21c43ccb82165d76e59fc062cb56b5d04d2/src/wp-includes
 /class-wp-query.php#L3324-L3334 example 2]). If the changes made to
 resolve the bug can be made more efficient by priming caches in a
 different way, then I think that's worth handling in a follow-up ticket if
 needed.

 As a side note, @SirLouen I appreciate the energy that you've put into
 reviewing and testing this functionality at a very deep level. However,
 some of your comments in this conversation have come across as accusatory
 and unproductive. @peterwilsoncc is a longstanding contributor to this
 project who is well respected for having good judgement and a deep
 knowledge of some of the application's most complex code. Asking for
 feedback in support of your own understanding is very welcome, but please
 refrain from assuming there is some ulterior motive.

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