It doesn’t make sense to limit results to a particular taxonomy term when requesting a single post. One normally wants that specific post and whatever terms are along for the ride. If you are using terms to limit which users can see a particular post, it’s best to check for these things on the single template just before output instead of trying to limit singular requests by terms in the query.
If you were able to use tax_query with singular queries and the query failed because the required term was not assigned to the post, WP would normally output a nothing found message where you should really want an access forbidden type of message. By verifying terms before output, you are able to output a more appropriate message instead of nothing found.
But then wouldn’t I have to have my permission logic in two formats in two places: once as part of WP_Query for non-single pages so that pagination and everything works, and then again on single pages as a function of the post ID?
And philosophically I’m of the opinion that if I supply a limitation to WP_Query, it should be applied and applied consistently. A date_query limitation works on single posts, but not a tax_query? This behavior should at least be documented somewhere.
Using taxonomies for user permissions isn’t what taxonomies were intended for. I do see why you chose this approach and your choice is reasonable. When we get “creative” with WP objects, we need to expect to encounter unanticipated issues.
Have you considered using meta_query for user permissions? Unconfirmed, but it appears meta queries are not tossed out with singular requests. I know the default meta data UI could be less than optimal. A custom meta box can resolve that.
I agree that the tax_query/singular issue should be documented. Unfortunately, documentation is often lacking in many places. We rely on volunteers to create documentation. Considering that, they are remarkably complete IMO. There is always room for improvement. I encourage you to at least submit a user note to one of the WP_Query pages so something is in writing, even if the user note area is a sub-optimal location.
I just came across the same issue and added notes to the codex entries for WP_Query and pre_get_posts about the is_singular issue. I don’t know how to update the docs at developer.wordpress.org, those seem locked down.
I got around the problem by using the posts_clauses filter and doing what the code at line 1960 would of done.
public function filter_posts_clauses( $clauses, $query ) {
if ( !$query->is_main_query() || empty( $query->query_vars['custom_query_var_foo'] ) ) {
return $clauses;
}
$tax_query = array(
array(
'taxonomy' => 'foobar',
'field' => 'slug',
'terms' => $query->query_vars['custom_query_var_foo'],
'include_children' => false,
),
);
$tax_query = new \WP_Tax_Query( $tax_query );
$tax_clauses = $tax_query->get_sql( $GLOBALS['wpdb']->posts, 'ID' );
$clauses['join'] .= $tax_clauses['join'];
$clauses['where'] .= $tax_clauses['where'];
return $clauses;
}
