Inconsistent behaviour in WP_Query with single category__and and tag__and query vars

[seanleavey]

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

[talldanwp]

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

[seanleavey]

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

[talldanwp]

@seanleavey - sorry, I meant [25238].