Add register_block_patterns action

[jsnajdr]

This issue continues discussion that started in #36751 (comment)

To let plugin authors reliably register block patterns (and categories) at the right time, we should introduce actions called register_block_patterns (sync) and register_remote_block_patterns (async).

The WordPress.com Editing Toolkit plugin currently registers new patterns on the current_screen action, but that stopped working with WordPress 6.0 beta 1, because patterns are now fetched from a new REST endpoint, which never calls current_screen.

Another thing that Editing Toolkit currently does is that it load different patterns for post editor and for site editor. It was able to detect that by looking at the $current_screen object. But in REST API we don't have a way to detect that. We'd have to add a new query parameter. That feature can't currently be ported to 6.0 beta 1.

Does the current vanilla Gutenberg have a way to discriminate between post and site editor (and possibly other ones, like widgets, too) and offer different blocks and block patterns in the inserter?

@youknowriad @mcsf @fullofcaffeine

[ellenbauer]

With Gutenberg 13.0.0 active patterns that include blocks from our other than core blocks seem to have lost their styling. Could it be that this is related to the issue mentioned above?
We have patterns including blocks from our AinoBlocks plugin that do not show any styling once the latest Gutenberg plugin release is active.

[WhiteHeatherClub]

I also have the same issue - Patterns containing non-core blocks are losing styling moving from Gutenberg 12.9 to 13:

[youknowriad]

Can we create a separate issue for the patterns losing styles. It's not clear at the moment if it's the same problem.

[johnstonphilip]

With this hook, it would be great to know the post_type, and possibly even the whole post object for context about what is being edited. This way I could register block patterns that are woocommerce specific, and contain blocks that should only be used on a product post_type, for example.

[jsnajdr]

To make that work, the REST endpoint would have to have a few query params, like:

GET /block-patterns/patterns?editor=edit-post&post_type=product&post_id=123

and the register_block_patterns hook would get that info as some "context" param.

This used to be possible with the current_screen hook and its WP_Block_Editor_Context object param, but the REST endpoint knows only its query params, nothing else.

[johnstonphilip]

@jsnajdr post_id might be enough, as I could do a get_post to check the post type.

[renatho]

With this hook, it would be great to know the post_type, and possibly even the whole post object for context about what is being edited. This way I could register block patterns that are woocommerce specific, and contain blocks that should only be used on a product post_type, for example.

Just to comment here that we're needing the same for Sensei LMS.

[renatho]

I was investigating that in order to come with a good solution to Sensei, but I noticed that it was fixed for the final release in this commit: WordPress/WordPress@571e1e0

So should we consider it safe to be registered attached to the current_screen hook (based on my tests, it works well)? If yes, I think we could also close this issue.

[jsnajdr]

So should we consider it safe to be registered attached to the current_screen hook.

It will work but is suboptimal because the patterns registered in current_screen are not visible by the block-patterns/patterns REST endpoint and need to be included in the editor's initial HTML markup.

If you don't need to discriminate between different kinds of editor (post, site, widgets, ...) and just want to register a pattern for all, currently the best action to use is init. Such a pattern will be in REST and the same action is used by Core and themes (like twentytwentytwo) to register their patterns.

There is still need for a new register_block_patterns action, which both i) registers patterns for REST endpoints and ii) allows to target particular editors. And also iii) provides an obvious tool for anyone who wants to register a pattern, without having to understand the lifecycles of the very general-purpose init and current_screen actions.

[jordesign]

@jsnajdr @annezazu As patterns are getting more robust - is this something worth considering starting up again - particularly to include the developer experience?

[annezazu]

Perhaps in a future release! I can't see this happening for 6.5 at this stage.