Allow for querying by `post_name__in`

[dd32]

When implementing WP_Query with external data-sources, I'm finding a common theme to being wanting to query by a selection of post slugs retrieved from an external system.

WordPress currently utilises post_id__in for sticky posts, and some plugins use the same query var. However, when you're integrating with another system which doesn't use WordPress post id's, the post slug is the most obvious field to use as the shared key.

For example, I'd love to be able to do this query:

$query = new WP_Query(
   'post_type' => 'post',
   'post_name__in' => array( 'sample-post', 'my-post', 'secret-projects' ),
   'meta_query' => array( ... ),
   'tax_query'  => array( ... ),
   'date_query' => array( ... ),
);

Right now, there's three main workarounds

1. Store post ID's along side the post_name
2. Retrieve all post ID's for the slugs, then pass those in as post_id__in
3. Using the posts_clauses filter to add a AND post_name IN(...) where clause.

[enshrined]

This adds the ability to pass a post_namein array to WP_Query for filtering

[enshrined]

Theres a basic version of it here but no tests. It adds the post_name__in array which is then ran through sanitize_title_for_query and added to the query.

[boonebgorges]

Thanks, enshrined. This is a helpful start. Some notes on the patch:

• array_map() doesn't operate on an array in place - you need to grab the return value. Ie $post_name__in = array_map( 'sanitize_title_for_query', $q['post_name__in'] )
• In the documentation, it looks like you're chopping up the $posts_per_archive_page lines :)
• I'd suggest moving the new block so that it's near the existing parsing for 'name' and 'pagename', perhaps even making it into an elseif condition alongside the name/pagename checks. This would make it clearer how the 'post_name__in' interacts with the existing parameters (which would be especially important if we introduced 'post_name__not_in').

[enshrined]

Hi @boonebgorges,

Thanks for that, did it late last night so must have just overlooked them. Here's an updated patch with the block moved to an elseif, docs fixed and the array_map correctly working.

I wasn't too sure whether to sit the block above or below the } elseif ( '' != $q['attachment'] ) { block. I've settled for below for now so as not to change any code that doesn't have to be but if you'd prefer it above that can also be done.

[enshrined]

Updated patch

[boonebgorges]

Thanks! Let's get some tests for this. https://core.trac.wordpress.org/browser/tags/4.2.2/tests/phpunit/tests/post/query.php is probably the right place.

[enshrined]

Tests for post_namein

[enshrined]

Attached is a test for whats there so far.

I'm not sure if it will be sufficient for what you need but if not, let me know what's needed and I'll get them written up!

[boonebgorges]

Tests look good. Thanks!

[boonebgorges]

In 33653:

Introduce post_name__in parameter for WP_Query.

Props enshrined.
Fixes #33065.

[ramiy]

Wrong name, it shuld be post_slug__in like tag_slug__in.

[dd32]

post_name__in matches a) The other name parameter, and b) the database column it's querying. You also refer to $post->post_name not $post->slug.

Similarly, Taxonomies are querying by slug as that's what their DB column is, and $term->slug.

[krogsgard]

Should this say @since 4.4 not @since 4.3?

[boonebgorges]

Replying to krogsgard:

Should this say @since 4.4 not @since 4.3?

*sigh* Yes. [33661]