Tags and Categories should have a "slugs" parameter for batch fetching

[wonderboymusic]

I have 8 categories but I want to query only 3:
1 taco
2 burrito
3 enchilada

/categories?slug=taco only returns one item because there is no batch slug mechanism

/categories?include[]=1&include[]=2&include[]=3 returns all 3

What I want:

/categories?slugs[]=taco&slugs[]=burrito&slugs[]=enchilada

The endpoints, by default, are way too slow to effectively be used with serial HTTP. The batching parameters are essential.

[kadamwhite]

From a design standpoint we've tried to make any list-style query parameter (include, exclude, categories, etc) behave the same... in this regard I agree that "slug" is the odd one out, because it is a filtering query that returns an array, but does not accept multiple values. I'm in favor of the change, as the benefit to clients is significant and the query overhead within WP should be significantly less of a burden than the HTTP latency or query overhead of making multiple requests in parallel or sequence

[jnylen0]

This is very similar to #38579 for posts. As Adam mentioned, we should use the same slug parameter but support arrays and comma-separated lists. Let's see if we can get it in the next minor release.

[MatheusGimenez]

I added array support in the parameter slug in this patch.

Example to use:
SITE_URL/wp-json/wp/v2/categories/?slug[]=slug-1&slug[]=slug-2

[curdin]

Updated functionality, Unit tests added

[curdin]

Hi,

I've added unit tests. I've also noticed that the slugs parameter was previously slug. For backwards compatibility my patch contains both, slug for a single parameter, slugs for an array. Happy to update if this is not expected.

[jnylen0]

@curdin we want to use slug only, see comment:2 above.

[danielbachhuber]

+1 to slug handling a single or multiple values. This should be standard across all endpoints.

Some prior conversation:

• ​https://github.com/WP-API/WP-API/issues/2065
• ​https://github.com/WP-API/WP-API/issues/642

[curdin]

Sure thing. I'm away for the next 3 days - I will send an updated patch on Monday.

[MatheusGimenez]

Replying to jnylen0:

@curdin we want to use slug only, see comment:2 above.

My patch already do this.

[curdin]

Apologies if it does, I was under the impression it only did arrays but not strings. I'll check it out and merge my unit tests, then resubmit the patch.

Replying to MatheusGimenez:

Replying to jnylen0:

@curdin we want to use slug only, see comment:2 above.

My patch already do this.

[curdin]

@MatheusGimenez - yep, sorry, my mistake.

I am adding patch now using your functional changes, and adding slug array unit tests to the category and tag controller tests.
This may be a question for another day but in ​https://github.com/WP-API/WP-API/issues/2065 there is discussion around posts and users also having slug filters. Should these also be amended to receive arrays?

[curdin]

Unit tests added to MatheusGimenez's patch

[jnylen0]

Replying to curdin:

This may be a question for another day but in ​https://github.com/WP-API/WP-API/issues/2065 there is discussion around posts and users also having slug filters. Should these also be amended to receive arrays?

The posts endpoint already supports filtering by multiple slugs, see #38579. If the users endpoint doesn't, then yes, we should add that too. Want to create a separate ticket for that?

I would like to see one of the new test_get_items_slug_array_arg tests changed to test_get_items_slug_csv_arg with the slugs passed as a comma-separated string like taco,burrito,enchilada. Otherwise 40027.3.diff​ looks good to me and I will test and commit it later this week.

[curdin]

Added CSV query arg tests

[curdin]

@jnylen0 Updated patch with CSV unit tests for both category and tags added above.

From my testing the user endpoint does not appear to accept an array or csv of slugs. I have opened #40213 to address this.

[swissspidy]

From what I can tell, the latest patch works as intended.

[jnylen0]

In 40027.5.diff​ I removed some duplicate tests and made some minor changes to the test logic. This is looking good to me - I'll commit after the test suite finishes running.

[jnylen0]

Remove duplicate tests

[jnylen0]

In 40376:

REST API: Allow fetching multiple terms at once via the slug parameter.

This matches a similar change previously made for posts (#38579) and an upcoming change for users (#40213).

Props wonderboymusic, MatheusGimenez, curdin.
Fixes #40027.

[jnylen0]

Reopening for backport to 4.7 branch.

[jnylen0]

I missed something in [40376] - really this commit should include a string change for consistency with the posts endpoint:

- Limit result set to terms with a specific slug.
+ Limit result set to terms with one or more specific slugs.

Last I heard, we don't do string changes in minor releases. With the longer release cycle for 4.8, should we leave this rule in place, or relax it?

[jnylen0]

Per ​Slack discussion this is not expressly forbidden, and we already have at least one other string change in 4.7.4. I'm going to go ahead and fix this.

[jnylen0]

In 40377:

REST API: Update description string of terms endpoint slug parameter.

As a follow-up to [40376], and for consistency with the posts endpoint, we should indicate in the description that the slug filter parameter can accept multiple values.

See #40027.

[ocean90]

Feel free to commit the string change, it doesn't necessary need to be in 4.7.4 though. Note that the other ticket isn't yet back-ported.

[swissspidy]

In 40427:

REST API: Allow fetching multiple terms at once via the slug parameter.

This matches a similar change previously made for posts (#38579) and an upcoming change for users (#40213).

Props wonderboymusic, MatheusGimenez, curdin.
Fixes #40027.

Merges [40376] to the 4.7 branch.

[swissspidy]

Note that I merged this to the 4.7 branch without the string change as none of the other string changes from the mentioned tickets have made it into this release. Better to keep it that way, given that we now release much earlier than originally planned.