[wp-trac] [WordPress Trac] #63255: WP_Query normalization can break plugin filters comparing query variables.

[WordPress Trac]

#63255: WP_Query normalization can break plugin filters comparing query variables.
--------------------------------------+------------------------
 Reporter:  peterwilsoncc             |       Owner:  joemcgill
     Type:  defect (bug)              |      Status:  reviewing
 Priority:  normal                    |   Milestone:  6.8
Component:  Query                     |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------------
Changes (by joemcgill):

 * owner:  (none) => joemcgill
 * status:  new => reviewing


Comment:

 Thanks for the gut check, @swissspidy! I'll admit that I've been battling
 an illness this week  and I did not fully grasp the concern that was being
 raised here when I first read through the ticket.

 Looking again today, it seems that if we want to maintain support for
 filters to expect to receive post types (or other normalized properties)
 from the query in a specific order, then we would need to normalize the
 cache key generation without affecting the order in which these actually
 get processed in the query. This may be doable, but also adds an
 additional level of complexity to cache key generation that seems
 undesirable — particularly when affected plugins can address this by
 sorting the the query properties before comparing (or using less brittle
 approaches, as Pascal suggests).

 Aa an example, using the use case @peterwilsoncc added to the issue
 description, this would be a simple way to fix broken filter callbacks
 that previously relied on specific array ordering:

 {{{#!php
 <?php
 $query = new WP_Query( array( 'post_type' => array( 'post', 'page' ) ) );

 add_filter( 'posts_where', function ( $where, $query ) {
         if ( sort( array( 'post', 'page' ) ) === $query->get( 'post_type'
 ) ) {
                 // Modify WHERE clause.
         }

         return $where;
 }, 10, 2 );
 }}}

 Given that it's also possible for other filter callbacks to affect the
 order of these values before they're passed through to other callbacks, I
 don't really think we should force back-compat in this case.

 Would love to hear feedback from @peterwilsoncc, @johnjamesjacoby, or
 @vortfu prior to finalizing this decision, but currently I think we should
 ship 6.8 as is and move this to 6.8.1 for visibility, in case there are
 other reports. If a revert is needed at that point we can ship it in
 6.8.1, otherwise close this as a wontfix.

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