Make WordPress Core

Opened 4 months ago

Last modified 2 months ago

#59903 new enhancement

Add user pattern categories to the pattern categories API response

Reported by: glendaviesnz's profile glendaviesnz Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: trunk
Component: REST API Keywords: has-patch
Focuses: Cc:

Description

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.

Change History (6)

This ticket was mentioned in PR #5621 on WordPress/wordpress-develop by @glendaviesnz.


4 months ago
#1

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

@TimothyBlynJacobs commented on PR #5621:


4 months ago
#2

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.

@TimothyBlynJacobs commented on PR #5621:


4 months ago
#3

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.

@TimothyBlynJacobs commented on PR #5621:


4 months ago
#4

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.

@glendaviesnz commented on PR #5621:


4 months ago
#5

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.

@glendaviesnz commented on PR #5621:


2 months ago
#6

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

Note: See TracTickets for help on using tickets.