Opened 13 years ago
Closed 10 years ago
#17199 closed enhancement (maybelater)
Unintuitive tax query 'operator' values
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Query | Keywords: | has-patch needs-refresh needs-docs close |
Focuses: | Cc: |
Description (last modified by )
Currently, the accepted values for the tax_query 'operator' arg are:
AND
, IN
and NOT IN
.
It would be better if they were instead:
AND
, OR
and NOT
.
which would be more intuitive and consistent with wp_list_filter().
Obviously, we would still have to keep backwards compatibility with the old values.
Attachments (2)
Change History (10)
#4
@
10 years ago
- Keywords has-patch added
- Milestone changed from Awaiting Review to 3.7
I don't know how important this is, moving to 3.7 for more discussion
#5
@
10 years ago
- Keywords needs-refresh commit needs-docs needs-codex added
This is fine. In lieu of in_array(), a straight-up check would be clearer and cleaner (incidentally also faster). So 'IN' == $operator || 'OR' == $operator
.
This will likely require some phpdoc changes? Codex changes?
#6
@
10 years ago
- Keywords commit removed
- Milestone changed from 3.7 to Future Release
I'm not a fan - IN/NOT IN are the MySQL operators. If aliases are done here, they should be done for meta and date queries too, if not elsewhere. And we also have things like post__not_in
- I don't think this is unintuitive, and certainly isn't any less intuitive than anything else that uses the same language.
Punting out of 3.7, anyway.
#7
@
10 years ago
- Keywords close added; needs-codex removed
I agree with Helen. If we were to change the operators here, we'd realistically need to do it in several other places as well. Probably not worth the confusion, but maybe that's just me.
#8
@
10 years ago
- Milestone Future Release deleted
- Resolution set to maybelater
- Status changed from new to closed
FWIW, I like this. To some, AND and OR are more natural for this particular situation. (They are *also* MySQL operators and OR and IN are very much related).
That said, this is low priority, in need of broad standardization, and ultimately not a big deal. Closing. Anyone is feel free to rescue this ticket later.
Agreed, OR rather than IN makes more sense and is more consistant. Same with NOT.