Make WordPress Core

Opened 8 years ago

Closed 8 years ago

#38579 closed enhancement (fixed)

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

Reported by: jnylen0's profile jnylen0 Owned by: rmccue's profile rmccue
Milestone: 4.7 Priority: normal
Severity: normal Version: 4.7
Component: REST API Keywords: has-patch has-unit-tests
Focuses: Cc:


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.

Attachments (1)

38579.diff (3.6 KB) - added by jnylen0 8 years ago.

Download all attachments as: .zip

Change History (11)

8 years ago

#1 @jnylen0
8 years ago

  • Keywords has-patch has-unit-tests added

#2 @rachelbaker
8 years ago

  • Keywords reporter-feedback added
  • Type changed from defect (bug) to enhancement

@jnylen0 This is not a bug. This is intentional behavior based on WP_Query and it's public query vars. See:

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?

#3 @jnylen0
8 years ago

  • Keywords reporter-feedback removed

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?

Version 0, edited 8 years ago by jnylen0 (next)

#4 @jnylen0
8 years ago

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.

#5 @joehoyle
8 years ago

@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.

#6 @rachelbaker
8 years ago

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?

#7 @jnylen0
8 years ago

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

#8 @rmccue
8 years ago

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.

#9 @rmccue
8 years ago

  • Milestone changed from Awaiting Review to 4.7
  • Owner set to rmccue
  • Status changed from new to accepted

#10 @rmccue
8 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 39093:

REST API: Allow querying for multiple slug values.

Props jnylen0, rachelbaker.
Fixes #38579.

Note: See TracTickets for help on using tickets.