&_embed only embedding first 10 categories

[manyourisms]

Normally our posts don't have more than 10 categories, but I did notice that when adding more than 10 to a post, a query using &_embed still only embedding the first 10. After searching through the class-wp-rest-server.php code, it doesn't seem like that should be the case, but alas! I'm too unfamiliar with how it is building the links for a post behind the scenes, but surely it must be happening there if I was to guess.

Hitting the category link href at wp-json/wp/v2/categories?post=<postId> also only returns 10 categories.

[manyourisms]

Response showing it only coming back with 10 categories

[manyourisms]

Edit post page showing much more than 10 categories for the post.

[kadamwhite]

Hitting the category link at wp-json/wp/v2/categories?post=<postId> and receiving 10 responses is expected; collections maintain standard pagination behavior when using query parameters like post=, so you can see the next page of responses with &page=2.

Only permitting up to 10 records to be embedded, however, is unexpected. Good catch! The origin of the issue appears to be that we use the REST API internally to embed links collections, and these requests obey the REST API's standard 10-post collection response limit. I'd definitely consider changing this to work in a more predictable way.

[manyourisms]

Wunderbar! Thanks for the clarification on the categories endpoint, sorry to have missed that.

Replying to kadamwhite:

Hitting the category link at wp-json/wp/v2/categories?post=<postId> and receiving 10 responses is expected; collections maintain standard pagination behavior when using query parameters like post=, so you can see the next page of responses with &page=2.

Only permitting up to 10 records to be embedded, however, is unexpected. Good catch! The origin of the issue appears to be that we use the REST API internally to embed links collections, and these requests obey the REST API's standard 10-post collection response limit. I'd definitely consider changing this to work in a more predictable way.

[rmccue]

@kadamwhite What sort of changes did you have in mind for making this more predictable?

[manyourisms]

Replying to rmccue:

@kadamwhite What sort of changes did you have in mind for making this more predictable?

I would think the page parameter would apply only to the main resource you are requesting, IE posts in this case. I would expect all embeds for those 10 resources to come back (unless there was an additional paging param for the embeds for some reason).

[kadamwhite]

I would also feel like we'd get back all embeds. If I have a resource that includes a link to that resource's categories, I would expect to be able to follow it and get a comprehensive list.

This obviously raises the question of how to handle situations (rare, but they happen) where one post may have 100+ tags or categories. I think to start we should hard-cap in that edge-case, but otherwise return a full list when embedded.

[TimothyBlynJacobs]

A naive solution to this would be to always append per_page=100 in WP_REST_Server::embed_links(). However that wouldn't be ideal for single routes, and we have no guarantee that collection routes actually implement their per_page cap at 100.

What we could do is inside of ::embed_links() use the new ::match_request_to_handler() and ::respond_to_request() methods to reimplement ::dispatch() but to first look if a per_page arg is registered and if so, find it's maximum value and apply it to the request.

@lpawlik are you interested in this one?

[lpawlik]

@TimothyBlynJacobs sure thing, I'll add it to my list 👍

Trac ticket: https://core.trac.wordpress.org/ticket/43439

Allow _embed to include all embedded object such as taxonomies, comments etc.

@TimothyBJacobs @spacedmonkey this is an initial commit for https://core.trac.wordpress.org/ticket/43439. It seems to be solving reported issue however, I am concerned about the fact that it's using \WP_REST_Server::match_request_to_handler that is modifying the state of passed request object, and the same method is called later via dispatch method. Is it our concern that it's called second time? Do you have any other ideas to address this issue?

[TimothyBlynJacobs]

Hey @lpawlik! Just following up on our ​conversation in Slack about how we could alleviate the duplicate matching issue.

[lpawlik]

Hey @TimothyBlynJacobs - thanks for the ping. I'll be working on this, later this week and I hope to have something ready for the review early next week :)