WP is the stable product. The philosophy to maintain backward compatibility means that once these are added, Core is stuck with them. So lets just call them stable.

If a future iteration of this code does end up using the rest API, these would be need to be maintained but become a wrapper for the API call.

I can't change the names, they are names of the settings fields that the wp.editPost.initializeEditor API expects. The consumer of the API doesn't get to choose them.

And we don't want the "pass the block patterns data object as a setting when initializing the editor" API to become stable, because using it causes performance issues. The block pattern data are 200kB even on vanilla WP with Twenty Twenty-Two, and they are slowing down the editor load and initialization. They should be loaded solely with REST endpoint.

This patch merely makes pattern registration in current_screen work again.

@jsnajdr that 200kB is my only concern here. Do you think there's any way to:

• Check if any additional patterns were registered by the extenders
• If yes, include the __experimentalBlockPatterns setting
• If not, do not include the __experimentalBlockPatterns setting

? Otherwise that 200+kB will always be a part of the config and will likely keep growing over time.

@adamziel When registering a pattern I could use a 'init' !== current_action() check to see if the pattern is being registered with an action different than init, where the REST API controller doesn't see it. And then the __experimentalBlockPatterns setting would include only these registered-outside-init patterns.

Most patterns are registered on init, e.g., Core and themes shipped with Core do that. We can rely on them to be sent in the REST response and don't need to include them in a big initial setting JSON.

What do you think?

I think that's a brilliant idea @jsnajdr! It saves everyone 200kB and only increases the config size for those developers who specifically want to do that. I don't see any downsides really.

@adamziel I implemented the idea in 7d32ca9. I'm going to update also the patch in WordPress/gutenberg#40818 and test them together.

One thing I'm unhappy about is the $outside_init_only parameter for the get_all_registered method. I don't want it to become a permanent part of the public API. It should be eventually removed after all patterns are registered the new way. Is there a way to flag it as "unstable"?

Tested this with patched Core, patched Gutenberg and the Blockmeister plugin. The result is that initial HTML has __experimentalBlockPatterns setting with just the patterns (and categories) registered by Blockmeister (I created one), and the rest is loaded with REST API. Namely the core/* and twentytwentytwo/* patterns, and the remote ones, featured patterns from wp.org. And the editor UI merges them together.

Once plugins move the registration to the recommended hooks, the HTML will become [] so I don't think it's a huge problem.

If I understand correctly, the fallback is for plugins that register the patterns on hooks that occur after the admin/front-end and REST API execution path fork.

I'm in the process of confirming, but it looks like that happens shortly after the wp_loaded hook fires so you might be able to do if ( ! did_action( 'wp_loaded' ) ) { /* don't populate config */ }.

I love this idea @jsnajdr, it's a really nice way to maintain the improvement without breaking back-compat.

All execution paths, frontend, admin and REST, execute the wp-settings.php file, with the actions that are there: plugin(s)_loaded, init and wp_loaded. And they diverge shortly after that. The REST path diverges in $wp->parse_request, where it hooks into the parse_request action, where if it detects a REST request it performs it and dies.