WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 6 years ago

Last modified 3 years ago

#9951 closed enhancement (duplicate)

Add [taxonomy]__in, [taxonomy]__not_in to wp_query

Reported by: joehoyle Owned by: MarkJaquith
Milestone: Priority: high
Severity: normal Version: 2.8
Component: Query Keywords: needs-patch early
Focuses: Cc:

Description (last modified by scribu)

Currently it's not possible to query for multiple custom taxonomy terms using query_posts the same way you can do tag__in, category__in, tag__not_in etc. I propose wp_query is extended to support querying by multiple custom taxonomy terms and also multiple custom taxonomies and terms.

For example, to get all posts that are in my 'Microsoft' term in the 'company' tax:

query_posts( array( 'company__in' => array( 5 ) ) ) //5 is the term_id for Microsoft

Multiple taxs with multiple terms:

query_posts( array( 
    'company__in' => array( 5, 10 ),
    'people__in'  => array( 11, 12, 13 ),
)); 

Basically: [tax]__in, [tax]__not_in and [tax]__slug_in should all work, in conjunction with tag__in etc.

I have written a patch that implements this, currently [tax]__in, [tax]__not_in, but [tax]__slug_in will be an easy addition.

As tag__in, category__in and all of those are no different, the patched lines I wrote could replace all those hardcoded statements fairly easily.

Attachments (4)

query.diff.txt (2.5 KB) - added by joehoyle 7 years ago.
Patch to allow [custom taxonomy]in in wp_query
query.diff (4.1 KB) - added by joehoyle 7 years ago.
Fixed problem with diff, sorry about that - not too used to all this svn crazyness!
query.2.diff (8.6 KB) - added by willmot 7 years ago.
Removed unneeded $join
tax-experimental.diff (8.4 KB) - added by joehoyle 7 years ago.
Added experimental patch which replaces all the category*, tag* to use all registered taxonomies. (not working)

Download all attachments as: .zip

Change History (31)

@joehoyle
7 years ago

Patch to allow [custom taxonomy]in in wp_query

#1 @ryan
7 years ago

  • Milestone changed from 2.8 to Future Release

Too late for 2.8. Postponing.

#2 @joehoyle
7 years ago

  • Keywords has-patch added

#3 follow-up: @westi
7 years ago

  • Cc westi added

-1 to current patch.

Much better if this was an explicit action caused by register_taxonomy that searching for xxx in query var names.

#4 @joehoyle
7 years ago

Modified the patch to not use strpos() on $qv names, now foreach's through global wp_taxonomies and does an array_key_exists() instead, let me know if I am heading in the wrong direction with this

#5 @Denis-de-Bernardy
7 years ago

  • Milestone changed from Future Release to 2.9

#6 @Denis-de-Bernardy
7 years ago

  • Keywords needs-patch added; has-patch removed
  • Milestone changed from 2.9 to Future Release
  • Priority changed from high to normal
File to patch: wp-includes/query.php
patching file wp-includes/query.php
Hunk #2 FAILED at 1920.
patch: **** malformed patch at line 85: \ No newline at end of file

@joehoyle
7 years ago

Fixed problem with diff, sorry about that - not too used to all this svn crazyness!

#7 @joehoyle
7 years ago

  • Keywords has-patch added; needs-patch removed

#8 @Denis-de-Bernardy
7 years ago

  • Keywords needs-review added

#9 @Denis-de-Bernardy
7 years ago

  • Milestone changed from Future Release to 2.9

#10 @johnbillion
7 years ago

  • Cc johnbillion@… added

@willmot
7 years ago

Removed unneeded $join

#11 @willmot
7 years ago

  • Cc willmot added
  • Keywords tested added

I have tested this against Wordpress 2.8.4 on a large site that is soon to be released.

The $join on line 1925 is not needed (it joins the taxonomy and term tables on when they are not used in the WHERE). Removing it speeds things up considerably, especially on installs which have thousands of terms.

Attached patch simply removes said line.

#12 @willmot
7 years ago

  • Priority changed from normal to high

Is there anything else that can be done by us to help get this into WordPress 2.9?

We are currently using the patch on two client sites and it would be better if this were in core so that I don't have to apply the patch again when 2.9 is released.

I think this patch should be high priority as there is currently no way to query using multiple taxonomies in WordPress.

Last edited 3 years ago by willmot (previous) (diff)

#13 @ryan
7 years ago

  • Keywords early added
  • Milestone changed from 2.9 to Future Release

It's too late for 2.9 due to the freeze. We can do it early in the next release.

By the way, your patch looks like it backs out some recent changes in trunk.

#14 @willmot
7 years ago

Shame that we couldn't get it into 2.9 as the original patch and ticket were submitted pre 2.8, ah well...

I will add another patch diff'd properly against trunk asap.

@joehoyle
7 years ago

Added experimental patch which replaces all the category*, tag* to use all registered taxonomies. (not working)

#15 in reply to: ↑ 3 ; follow-up: @scribu
7 years ago

  • Component changed from Taxonomy to Query
  • Keywords needs-patch added; has-patch needs-review tested removed
  • Milestone changed from Future Release to 3.0
  • Owner changed from filosofo to ryan

Replying to westi:

-1 to current patch.

Much better if this was an explicit action caused by register_taxonomy that searching for xxx in query var names.

Agree: You should just be able to do my_term=foo&my_other_term=bar

#16 in reply to: ↑ 15 @joehoyle
7 years ago

Replying to scribu:

Replying to westi:

-1 to current patch.

Much better if this was an explicit action caused by register_taxonomy that searching for xxx in query var names.

Agree: You should just be able to do my_term=foo&my_other_term=bar

Don't quite understand what you mean here. Do you mean add another arg to register_taxonomy() to specify a query var to be used in query_posts()?

#17 @scribu
7 years ago

Do you mean add another arg to register_taxonomy() to specify a query var to be used in query_posts()?

The query_var argument is already available: http://core.trac.wordpress.org/browser/tags/2.9.1/wp-includes/taxonomy.php#L167

Say you have a 'genre' custom taxonomy.

If it's hierarchical, these are the query vars that should become available:

'genre', 'genre__in', 'genre__not_in', 'genre__and'

...in other words, the exact same query vars that are currently available for categories.

If it's not hierarchical, these are the query vars that should become available:

'genre', 'genre__in', 'genre__not_in', 'genre__and', 'genre_slug__in', 'genre_slug__and'

...in other words, the exact same query vars that are currently available for tags.

#18 @nacin
7 years ago

  • Milestone changed from 3.0 to Future Release
  • Owner changed from ryan to MarkJaquith
  • Status changed from new to assigned

Moving to future for now. I know MarkJaquith was working on a possible new API for this.

#19 @scribu
7 years ago

Related: #12413

#20 @simonwheatley
6 years ago

  • Cc simon@… added

#21 @markjaquith
6 years ago

Related (more ambitious): #12891

These things are not necessarily mutually exclusive. What I'm proposing is more of an advanced API specifically for multi-taxonomy queries. It'd be overkill for some simple OR examples that this ticket could handle.

#22 @ptahdunbar
6 years ago

  • Cc trac@… added

#23 @beaulebens
6 years ago

  • Cc beau@… added

#24 @scribu
6 years ago

Marked #14351 as dup of this.

#25 @scribu
6 years ago

  • Description modified (diff)

#26 @scribu
6 years ago

Marked #14620 as dup of this.

#27 @scribu
6 years ago

  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from assigned to closed

Marking this as duplicate of #12891 so we have a single place for discussion.

Note: See TracTickets for help on using tickets.