Add user pattern categories to the pattern categories API response

[glendaviesnz]

Currently user pattern categories and block pattern categories are merged in a number of places in the editor front end. It makes sense to do tis in a single place and the block-patterns/categories endpoint seems the obvious place to do that.

There is a Gutenberg PR (​https://github.com/WordPress/gutenberg/pull/55822) that adds the user pattern categories only if the source query param is specified and includes user.

Also added is a new id field as this is needed to map the user categories back to the taxonomy terms in certain parts of the UI. This field is only returned if id is explicitly requeste in the _fields param.

To see the added data the endpoint has to be called with params _fields: 'name,label,description, id' and source: [ 'core', 'user' ].

There is a related core PR (​https://github.com/WordPress/wordpress-develop/pull/5621) but this should only be merged once the GB PR is finalised and approved.

Currently just a draft PR to get some feedback on adding user pattern categories into the block-patterns/categories endpoint to check that we are doing this in a standard and backward compatible way.

This PR adds the user pattern categories only if the source query param is specified and includes user.

Also added is a new id field as this is needed to map the user categories back to the taxonomy terms in certain parts of the UI. This field is only returned if id is explicitly request in the _fields param.

So to see the added data the endpoint has to be called with params _fields: 'name,label,description, id' and source: [ 'core', 'user' ],

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

It seems a bit less than ideal that we are now making a database call, but this endpoint isn't paginated. What would it look like to support pagination?

It's also unfortunate that this API shape does not match the terms controller which it is now returning data for, the name property is backward.

It seems a bit less than ideal that we are now making a database call, but this endpoint isn't paginated. What would it look like to support pagination?

It's also unfortunate that this API shape does not match the terms controller which it is now returning data for, the name property is backward.

Have you considered what this would look like as a search controller type via WP_REST_Search_Handler with a subtype for user and core?

That would solve the different shape issues and is the more canonical way of handling similar but disparate data types in a single REST API request.

Thanks for the pointer to WP_REST_Search_Handler @TimothyBJacobs, I will take a look at that and see if that is a better option.

Going to close this for now - not sure if I will get it sorted before 6.5