[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
-------------------------------------------------+-------------------------

Comment (by SirLouen):

 Replying to @joemcgill
 > 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.

 This is a problem I've been raising lately for the test team improvement.
 In fact, I see it the other way around, not a bad thing to having an
 ulterior motive (i.e., use-case), and promoting it. Not showcasing a real-
 life (or somewhat real-life) use-case is what sometimes makes things
 difficult to understand/view, debug or test and think around the box for
 the Testing team and keeps judgment exclusive for (citing your words)
 members "with a deep knowledge of some of the application's most complex
 code".

 What I'm a little dubious about how healthy could be for a big foss
 project like this, and I'm not gonna lie here, is the "you cook and you
 eat your code" philosophy. I was not planning to bring this here to a
 report, but you mentioned it. What I mean with this, is that patches are
 peer-reviewed between committers, without another governing body (testing
 team), interceding in the process. But if we want to talk more deeply
 about this, I think we should raise it slack maybe in either #core-test or
 #core channels, please ping me there and I will be happy to discuss
 further.

 But let's go back to the issue here:
 I was reading the official docs and according to them these are the
 expected behaviors:
 https://developer.wordpress.org/reference/classes/wp_query/

 When using the `fields` parameter, we are going to expect a WP_Query that
 returns only `stdClass` objects with the ID of post parent:

 {{{

 Return Fields Parameter

 Set return values.

     fields (string) – Which fields to return. There are three options:
         'all' – Return all fields (default).
         'ids' – Return an array of post IDs.
         'id=>parent' – Return an array of stdClass objects with ID and
 post_parent properties.

 Passing anything else will return all fields (default) – an array of post
 objects.
 }}}

 Here you're forcing a full hydration as if `all` property was set in all
 cases, which will make underperformant all the use-cases where
 `id=>parent` were taking advantage (as I've been proposing in my
 examples).

 > 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.

 Now I'm asking, where is this documented? Because I've been browsing the
 docs for a while and I can't find traces of this.

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