[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.1
Component:  Query                     |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------------

Comment (by peterwilsoncc):

 > For instance, Jetpack appends the comics post type without re-sorting:
 https://wpdirectory.net/search/01JRJGRVBBT7Y5FWV4ZP833G67.

 I think that's fine, there's never been any benefit to resorting.
 Standardization happens after `pre_get_posts` but any modifications on the
 SQL clauses' filters will not be standardized by core and will need to be
 handled by plugins.

 > Instead of change the query args, could we consider only going this
 normalisation as part of the cache key generation? Would not the benefit
 but would have some benefit.

 I did a thought experiment on this and came to the view it would be very
 flaky. It would involve:

 * keeping track of which `query_vars` were standardized prior to this
 change and continuing to do so
 * cloning `query_vars` in to `cache_vars` or whatever
 * modifying `::set()` to update both
 * magic methods to update both when the public property is updated
 directly
 * standardizing the new property & using that to generate the SQL,
 requiring duplication of a lot of code in an already chunky method.

 ----

 Given there is some standardization in the class already, I don't want to
 commit to retaining some values but not others. If it's decided to revet,
 I think it's best to drop the tests I've included for that. (Here's a
 [https://gist.github.com/peterwilsoncc/58502f06dc6df114aca00f74d6035927
 gist of failing tests on 6.7]).

 If there is a revert, I think it can be done in the 6.8 branch to allow
 for an extended lead time whenever 6.9 is released.

 Of course, the final decision remains with @desrosj @joemcgill and
 @Mamaduka as tech leads for 6.8.

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