[wp-trac] [WordPress Trac] #31383: Add WP_Tax_Query support to WP_User_Query

[WordPress Trac]

#31383: Add WP_Tax_Query support to WP_User_Query
-----------------------------+-----------------------------
 Reporter:  desrosj          |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Future Release
Component:  Query            |     Version:  4.2
 Severity:  normal           |  Resolution:
 Keywords:  needs-patch      |     Focuses:
-----------------------------+-----------------------------

Comment (by boonebgorges):

 @desrosj Thanks for your patch on this ticket, and apologies for letting
 it fall through the cracks. Your patch is a useful starting point.

 @chrisvanpatten asks:

 > Also, what would be the minimum 'scope of work' on this ticket? Should
 we just aim to get tax_query in, and then leave UX concerns (taxonomies
 showing up in the Users menu, edit fields on the User page, etc.) to a
 future/separate ticket?

 This is a great question. I definitely think that 'tax_query' support can
 be worked on as a standalone patch. (More on [attachment:User WP_Tax_Query
 support.patch] in a moment.) In a pinch, I think we could put 'tax_query'
 support into a release without any user-facing UX.

 That said, I think it would make for a more compelling feature if we could
 flesh out some of the UX stuff as part of a single release. The operating
 slogan is, I think, something like this: "If my plugin registers a
 taxonomy with object type 'user', it should feel like a native part of
 WP." Obviously, there's some room for interpretation regarding what that
 means. But I'd say that, at a minimum, it covers the first two items I
 mentioned [comment:1 in my first comment]: admin menu placement and a
 better fallback for 'update_count_callback'. (The latter is not strictly
 user-facing, but it does determine the counts that are shown to users.)
 These two features, plus 'tax_query' in `WP_User_Query`, seem like a
 pretty good first pass.

 A good next step is a refresh of [attachment:User WP_Tax_Query
 support.patch]. Here are some notes:
 - `parse_tax_query()` doesn't check to see whether the requested
 taxonomies are assigned to the 'user' object. Should it? We don't
 currently do this elsewhere with 'tax_query' - for example, in `WP_Query`
 we don't check to see whether the taxonomies match `post_type`, even
 though taxonomies are registered against a `post_type` object. But the
 potential for confusion rises if we're providing more "official" support
 for user taxonomies. Here's a way to frame the issue: are we likely to
 confuse developers if we allow (ie, don't throw errors for) queries like
 `get_users( ... 'tax_query' => ... 'taxonomy=post_tag' )`? Or `get_posts(
 ... 'tax_query' => ... 'taxonomy=some_user_taxonomy' )`? Or maybe these
 queries will just always end up empty? We should think through the
 possible confusions (or, maybe, lack thereof).

 - It looks like the URL parsing (`$t->query_var` etc) is copied from
 `WP_Query`. `WP_Query` is responsible for the main query, which involves
 parsing query vars from the URL. `WP_User_Query` doesn't currently do
 this, so I think we don't need URL support here. If we introduce user-tax
 archives, we might consider it - but this is a way off (we don't currently
 have *any* front-end listings of users built into our theme hierarchy).

 - We'll need inline docs and unit tests.

 Thanks for your interest in the ticket! It would be wonderful to see the
 project move forward.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/31383#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform