[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:  2nd-opinion dev-feedback has-patch   |     Focuses:
  has-unit-tests                                 |  performance
-------------------------------------------------+-------------------------

Comment (by SirLouen):

 I've got some time before going to bed to review the main test (The test I
 believe is more conflictive).

 This is my version, I have changed:
 1. The 3 `get_the_*` with the post ID (`self::$page_child_ids[0]`), as a
 parameter, to get the expected result. If we have this parameter available
 why dont we use it? Its not a workaround, its available there.
 2. I have removed the `assertSameSetsWithIndex` because obviously, this
 test is only meant to validate your hyphotesis that WP_Query with
 `id=>parent` is not fully popualted by default, but its really not testing
 anything.

 {{{#!php
 <?php
         /**
          * Ensure that a secondary loop populates the global post
 completely regardless of the fields parameter.
          *
          * @ticket 56992
          *
          * @dataProvider data_the_loop_fields
          *
          * @param string $fields Fields parameter for use in the query.
          */
         public function
 test_the_loop_populates_the_global_post_completely( $fields ) {
                 $query = new WP_Query(
                         array(
                                 'fields'    => $fields,
                                 'post_type' => 'page',
                                 'page_id'   => self::$page_child_ids[0],
                         )
                 );

                 $this->assertNotEmpty( $query->posts, 'The query is
 expected to return results' );

                 // Start the loop.
                 $query->the_post();

                 // Get the global post and specific post.
                 $global_post   = get_post();
                 $specific_post = get_post( self::$page_child_ids[0],
 ARRAY_A );

                 // Use the post ID parameter for these functions
                 $this->assertNotEmpty( get_the_title(
 self::$page_child_ids[0] ), 'The title is expected to be populated.' );
                 $this->assertNotEmpty( get_the_content( null, false,
 self::$page_child_ids[0] ), 'The content is expected to be populated.' );
                 $this->assertNotEmpty( get_the_excerpt(
 self::$page_child_ids[0] ), 'The excerpt is expected to be populated.' );

                 // $this->assertSameSetsWithIndex( $specific_post,
 $global_post->to_array(), 'The global post is expected to be fully
 populated.' );
         }
 }}}

 I've tested this with the `6.7.1-alpha-59396-src` and got: `OK (4 tests,
 16 assertions)` as expected

 The rest of the tests I should take a better look, but at this point, I
 believe that this test alone is the main pillar of this whole report.

 I also believe that priming the cache is something that anyone could be
 doing in their app if they find it relevant for performance purposes, and
 is what the other test feel to be about (checking if the number of queries
 match the priming fact). The last tests seem to be related with the side
 effects of this patch, inflicted in the editor so I think I don't need to
 go into that part.

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