WordPress.org

Make WordPress Core

Opened 7 months ago

Closed 7 months ago

Last modified 7 months ago

#46459 closed defect (bug) (duplicate)

Inconsistent behaviour in WP_Query with single category__and and tag__and query vars

Reported by: seanleavey Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Query Keywords:
Focuses: Cc:
PR Number:

Description

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:

<?php
                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
7 months 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
7 months ago

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

#3 @talldanwp
7 months ago

@seanleavey - sorry, I meant [25238].

Note: See TracTickets for help on using tickets.