Make WordPress Core

Opened 13 years ago

Closed 10 years ago

#17199 closed enhancement (maybelater)

Unintuitive tax query 'operator' values

Reported by: scribu's profile scribu Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Query Keywords: has-patch needs-refresh needs-docs close
Focuses: Cc:

Description (last modified by scribu)

Currently, the accepted values for the tax_query 'operator' arg are:


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)

17199.diff (718 bytes) - added by wonderboymusic 10 years ago.
17199.2.diff (721 bytes) - added by wonderboymusic 10 years ago.

Download all attachments as: .zip

Change History (10)

#1 @scribu
13 years ago

  • Component changed from General to Query

#2 @scribu
13 years ago

  • Description modified (diff)

#3 @dwenaus
11 years ago

Agreed, OR rather than IN makes more sense and is more consistant. Same with NOT.

#4 @wonderboymusic
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 @nacin
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 @helen
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 @DrewAPicture
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 @nacin
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.

Note: See TracTickets for help on using tickets.