Pattern Directory API: Add support for pagination parameters

[ryelle]

This PR enables passing pagination parameters through to the pattern directory API request. In meta-12147, the hard-coded per_page and order values were removed, allowing paginated queries. But the connecting API in WordPress/Gutenberg doesn't support those - yet.

The pattern directory explorer here #45237 will need these parameters to support pagination and ordering patterns using the same sort as wordpress.org/patterns.

This PR sets up an allowed-list of query parameters that are passed through to api.wordpress.org. If/when more are needed, they can be added to the list.

Testing Instructions

1. Ensure the remote patterns are still loading in the editor — the Featured query, the core patterns, and any theme-added patterns.

Test the API endpoint in a REST client.

1. Try pagination, ex: /wp-json/wp/v2/pattern-directory/patterns/?per_page=6&page=2 — It should show the middle 6 patterns on wordpress.org/patterns/.
2. Try order: /wp-json/wp/v2/pattern-directory/patterns/?category=37&per_page=3&orderby=date&order=asc — should show the last 3 items on wordpress.org/patterns/categories/footer/page/2/
3. Make sure search still works /wp-json/wp/v2/pattern-directory/patterns/?search=plants — should match wordpress.org/patterns/search/plants/
4. Make sure slug still works /wp-json/wp/v2/pattern-directory/patterns/?slug=centered-text-title-with-two-columns — should return a single pattern

[ntsekouras]

Thanks for the PR @ryelle! Just noting that with php changes we will also need some tests.

[ntsekouras]

Thanks @ryelle, this is really close! We still need to add php tests for these changes.

[ryelle]

We still need to add php tests for these changes.

Is there an example or documentation somewhere about what tests exactly are needed?

[ntsekouras]

We still need to add php tests for these changes.

Is there an example or documentation somewhere about what tests exactly are needed?

I'm not sure about where the docs could be, but you can see the current tests in core here: https://github.com/WordPress/wordpress-develop/blob/trunk/tests/phpunit/tests/rest-api/rest-pattern-directory-controller.php., and a GB example of overriding just a few tests is: https://github.com/WordPress/gutenberg/blob/trunk/phpunit/class-gutenberg-rest-block-patterns-controller-test.php.

So you create a new file for the controller in phpunit folder and add the tests for the new/updated things in your PR. You'll need similar tests to test_get_items_search - for example for per_page you'll have to set that prop to the request and then test the returned results.

I'm not sure we need tests for get_collection_params change here. I couldn't find related tests in core, but I think there is something like a snapshot that will need updating when porting.. --cc @spacedmonkey

[ryelle]

I've added tests, but I don't know if I'm being too clever about it — instead of setting up a bunch of mocked responses, I'm capturing the requested wp.org API URL and confirming that the parameters passed in match those requested from wp.org. The other way (the way the current get_items_* tests are) would require a lot of fixtures and also seems more like testing the tests, not checking that the request is correct.

[ntsekouras]

Thanks for adding the tests and your work @ryelle!

instead of setting up a bunch of mocked responses, I'm capturing the requested wp.org API URL and confirming that the parameters passed in match those requested from wp.org.

I think we should do it like core does and add some fixtures. It should be possible to just update the search fixture(copy from core first and append some items if needed). I don't think we should need to add many more data or new fixtures(if any).

[ryelle]

I think we should do it like core does and add some fixtures. It should be possible to just update the search fixture(copy from core first and append some items if needed). I don't think we should need to add many more data or new fixtures(if any).

Maybe I'm misunderstanding how the tests work, but I thought it would be a fixture per test-case? At least, it seems that way from the get_raw_response function, because each mocked response matches the endpoint requested from wp.org.

This is also why the core tests feel like testing the tests — it's mocking the response, then making sure the response is what is expected, not making sure the request is the expected request. Making sure the response matches the schema makes sense in test_get_items, but feels redundant in the other tests. It's possible I'm thinking about it wrong, though. @iandunn, you wrote these tests initially, do you have any insight here? (it was quite a while ago…)

[ntsekouras]

This is also why the core tests feel like testing the tests — it's mocking the response, then making sure the response is what is expected, not making sure the request is the expected request. Making sure the response matches the schema makes sense in test_get_items, but feels redundant in the other tests.

TBH I didn't look extensively the other tests because I'm travelling right now, but what you say makes sense. I'll take a closer look as soon as I can.

[ntsekouras]

Thanks so much @ryelle, looks good!

[bph]

Flagged it for Needs Dev Note to have a blurb in the 'Miscellaneous Dev Note', maybe.