Choose the relationship between the meta_query and what it's pulled into (AND/OR)

[sc0ttkclark]

The use case for this is that I'd like to be able to, much like meta_query's "relation" option, be able to choose whether or not 'meta_query' itself should be treated like AND or OR in it's WHERE inclusion.

meta_query's "relation" option is already helpful, letting you treat any of the meta_query's arrays as OR instead of the default AND.

Adding this new option would provide the ability to treat meta_query as AND / OR based on the need of the WP_Query lookup.

[sc0ttkclark]

Oops! Wrong patch selected the first time :)

[johnbillion]

If you set the 'query_relation' parameter to OR in a given query, are you sure it has the desired effect? It will fetch anything at all which matches your meta query, regardless of any of the other arguments such as post type, post status, etc. I believe it will also affect any query parameter that comes after the meta query in the SQL due to the placement of the OR.

[sc0ttkclark]

Actually you are correct @johnbillion, I was working on this solution for a friend who needed it to do as was explained, however there are flaws in it that make it more of an edge case. One main attraction to this is that even though it operates as you said - main arguments OR meta query match - it runs (sans filters) as the last of the 'where' clauses built out, so it's use isn't negated from what I explained above.

Here's an example:

$my_query = WP_Query( array(
	'post_type' => 'any',
	'cat' => 4,
	'meta_query' => array(
		'query_relation' => 'OR',
		array(
			'key' => 'super_post',
			'value' => 1
		)
	)
) );

[wonderboymusic]

I think this is better accomplished with a LEFT JOIN - I added a patch here #19653. The reason for an OR is because you want posts that potentially have a meta key/value but don't care if they don't? That's a LEFT JOIN.

[sc0ttkclark]

The specific use case here was that 'query_relation' could handle matching meta_query array OR the other query args (like tax_query, author, etc).

[sc0ttkclark]

I'm wondering if your patch from #19653 would be a prerequisite to this ticket + patch, not a replacement..