WordPress.org

Make WordPress Core

Opened 9 years ago

Closed 6 years ago

#17199 closed enhancement (maybelater)

Unintuitive tax query 'operator' values

Reported by: 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:

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)

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

Download all attachments as: .zip

Change History (10)

#1 @scribu
9 years ago

  • Component changed from General to Query

#2 @scribu
9 years ago

  • Description modified (diff)

#3 @dwenaus
7 years ago

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

@wonderboymusic
7 years ago

#4 @wonderboymusic
7 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
6 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
6 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
6 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
6 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.