Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#46459 closed defect (bug) (duplicate)

Inconsistent behaviour in WP_Query with single category__and and tag__and query vars

Reported by: seanleavey's profile seanleavey Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Query Keywords:
Focuses: Cc:


In WP_Query::parse_tax_query, some code identifies if the submitted category__and query var contains only one entry, and if so, merges it into category__in:

                if ( ! empty( $q['category__and'] ) && 1 === count( (array) $q['category__and'] ) ) {
                        $q['category__and'] = (array) $q['category__and'];
                        if ( ! isset( $q['category__in'] ) ) {
                                $q['category__in'] = array();
                        $q['category__in'][] = absint( reset( $q['category__and'] ) );
                        unset( $q['category__and'] );

This doesn't effect the returned results (a singular AND query can be interpreted as a single OR), but this behaviour is not consistently applied to singular tags in tag__and. Since WP_Query rewrites the contents of the query vars, though, this has ramifications for plugins that use the contents of these query vars.

In my case, my plugin shows the contents of these query vars on the front end, and having items jump between query vars in the case of categories but not for tags may lead to confusion. I'm struggling to think why this behaviour is applied to categories but not tags, but I don't see why it can't be applied to both (or neither).

Change History (3)

#1 @talldanwp
5 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed
  • Version trunk deleted

@seanleavey - It looks like the change made to category__and originally occurred in #25238.

Some of the history of that change can be read at #16706. It appears to have been made as an optimization originally just to improve performance for categories. There was some intention to apply the changes more widely in that ticket and it looks like that should really have happened so that the edge-case for categories doesn't remain.

I'll close this ticket in favour of #16706, where this workaround can likely be reverted in favour of a more complete solution.

#2 @seanleavey
5 years ago

@talldanwp, thanks, but I don't see anything relevant in #25238 - is this the correct ticket?

#3 @talldanwp
5 years ago

@seanleavey - sorry, I meant [25238].

Note: See TracTickets for help on using tickets.