Ticket #15350 (closed defect (bug): fixed)
WP_Query Assumes Taxonomy Query Operator
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Priority: | normal | Milestone: | 3.1 |
| Component: | Query | Version: | 3.1 |
| Severity: | normal | Keywords: | |
| Cc: |
Description
The following query works in WP 3.0 and seems to be syntactically valid:
query_posts( array( 'taxonomy' => 'post_tag', 'term' => 'my term', ) );
However, trunk throws a notice because no operator is defined.
Patch checks for the operator to be set before attempting to evaluate it.
Attachments
Change History
- Keywords has-patch removed
That will prevent the appropriate query flag from being set.
- Status changed from new to closed
- Resolution set to fixed
- Status changed from closed to reopened
- Resolution fixed deleted
OK, but that changes existing behavior.
In 3.0:
query_posts( array( 'taxonomy' => 'post_tag', 'term' => 'my tag', ) ); var_dump( is_tax() ); // false
With r16258:
query_posts( array( 'taxonomy' => 'post_tag', 'term' => 'my tag', ) ); var_dump( is_tax() ); // true
Is this change of behavior intentional?
What can't you reproduce? The 3.0 behavior or trunk behavior?
r163258 is the proximate cause, because prior to that the above query has no operator set (that's what this ticket is about).
From wp-includes/query.php:
1576 foreach ( $q['tax_query'] as $query ) {
1577 if ( 'IN' == $query['operator'] ) {
1578 switch ( $query['taxonomy'] ) {
1579 case 'category':
1580 $this->is_category = true;
1581 break;
1582 case 'post_tag':
1583 $this->is_tag = true;
1584 break;
1585 default:
1586 $this->is_tax = true;
1587 }
1588 }
1589 }
According to the above, if the operator isn't IN, then is_category and is_tag will not be true.
An operator should always be present.
Otherwise, a correct check would be:
if ( !isset( $query['operator'] ) || 'IN' == $query['operator'] ) {

