REST API: Allow listing posts that match any of a set of slugs rather than just one

[jnylen0]

In #38553 we started looking at inconsistencies in how array values are handled across the API. We already support querying based on an array of attributes in lots of other places; let's improve consistency by supporting this for post slugs too.

[rachelbaker]

@jnylen0 This is not a bug. This is intentional behavior based on WP_Query and it's public query vars. See: ​https://codex.wordpress.org/Class_Reference/WP_Query#Post_.26_Page_Parameters

name is a public WP_Query string argument for returning the one item that matches a given post slug. post_name__inis a private WP_Query array argument.

We do not want to remove the name collection argument at all. You can still use post_name__in with authenticated users OR by adding it to the rest_query_vars filter.

I am not convinced there is a big enough need to support the post_name__in query argument across all installs. Can you give me some use-cases?

[jnylen0]

I'm mainly trying to improve consistency across different arguments, and continuing with similar tasks as #38553. You can already query by post IDs for example, and querying by slug seems likely to be even more useful than that.

When querying by a single slug, this changes the generated SQL from WHERE name = '...' to WHERE name IN ('...'). This didn't seem like a problem to me, and I don't understand why removing name would be a problem either given that there is still a way to do the same thing.

You can still use post_name__in with authenticated users OR by adding it to the rest_query_vars filter.

This is not supported out of the box though, correct?

[jnylen0]

To clarify my last comment a bit, I don't understand the distinction you've made between public and private query vars. I didn't see any functionality that I removed here (now that filter is gone) but let me know if that's not right.

[joehoyle]

@jnylen0 I think @rachelbaker's point is _by default_ for whatever reason, WordPress considers asking for multiple slugs to be a private_query_vars, that's why this is not available out of the box, as the rest api respects the public_query_vars.

However, of course in this case, it's fairy easy to see that there's not really any downside to disregarding the fact that it's a private query var.

[rachelbaker]

I have no problem with adding support for getting multiple posts by an array of slugs. I am against removing our current "get a single post from a post_name" slug collection parameter and replacing it with "get multiple posts from an array of slugs" slugs collection parameter.
Maybe we just add support for slugs?

[jnylen0]

¯\_(ツ)_/¯ I'd rather just keep the current singular slug support than have two separate properties.

[rmccue]

I think allowing multiple values for the field is fine; the singular slug keeps it consistent with the field in the resource, and I don't see any huge issues with allowing that to be a multi-value. We already do this with author and parent.

[rmccue]

In 39093:

REST API: Allow querying for multiple slug values.

Props jnylen0, rachelbaker.
Fixes #38579.