[WIP] Blocks: Make the block registration filterable on the server

[gziolo]

[UPDATE: moved to #6733]

Description

Implements: #2751, #4116.
Replaces: #5652.

The updated plan is as follows (originally shared in #5652):

• register_block_type is going to be the only way to register dynamic block and it needs to happen on the server
• attributes, supports, category, title?, description? will have to be registered on the server. It will be possible to update them only with the PHP hook.
• All other properties will be provided on the client using extendBlockType with the new corresponding JS hook.
• registerBlockType will remain with deprecation message for the next 2-3 releases to make sure developers have time to refactor their plugins.

Screenshots (jpeg or gifs if applicable):

There should be no visual changes.

Types of changes

Breaking change with the deprecation strategy to be proposed.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code has proper inline documentation.

[youknowriad]

Why is this on the client?

[gziolo]

I don't like this property at all :) I will move it to the server, too 👍

[gziolo]

To make things easier, I moved isPrivate to supports property and renamed to insertable.

[youknowriad]

Any reason this is limited to dynamic blocs?

[youknowriad]

What about the title and description? It seems to me that blocks discovery would benefit from these properties being declared on the server as well

[gziolo]

I'm going back and forth with those two. After another round of musings, I think it makes sense to move them to the server. In addition, we should move non-SVG version of the icon. This might allow lazy loading of blocks on the client because we would have something to display in the inserters.

Everything JS-based becomes a progressive enhancement loaded on the client when requested.

[gziolo]

I moved title, description, icon and keywords to the server, too.

[gziolo]

Any reason this is limited to dynamic blocs?

Just to keep the scope of the PR smaller. I would like to divide the efforts into 2 chunks. First, I'd like to refactor all dynamic blocks and provide deprecation strategy to that area. In the long run it should be enforced to declare all the properties listed in this PR on the server.

Next step would be to convert all static blocks to be server-side rendered and promote such usage.

@mtias suggested keeping the client-side registration for very simple blocks forever. We will need to come up with a set of rules when that would be possible. The biggest issue we discovered so far is when hooks updates attributes schema. My personal preference would be to have it possible only on the server to make sure that it happens in one place and it ensures that dynamic blocks have always the same schema on the server and the client.

[nb]

How is this related to #4841?

[aduth]

registerBlockType will remain with deprecation message for the next 2-3 releases to make sure developers have time to refactor their plugins.

If someone wanted to implement a Gutenberg editor outside a WordPress context, how would they do so without being able to register a block? We're limiting capabilities of the client, when we should continue to treat it as first-class, even if data is being pre-loaded by the server. The benefits of registering blocks on the server should be obvious enough to entice plugin authors into doing so.

[mcsf]

suggested keeping the client-side registration for very simple blocks forever. We will need to come up with a set of rules when that would be possible

This is tricky. On one hand, I was going to comment that we can keep the client-side interface with no restrictions if we make it clear — through naming, foremost — that it's meant for debugging and quick prototyping, thus making it acceptable for the very smallest plugins to use it if they so choose. On the other hand, it's hard to reconcile with:

If someone wanted to implement a Gutenberg editor outside a WordPress context, how would they do so without being able to register a block? We're limiting capabilities of the client, when we should continue to treat it as first-class

I mean, we could say that the server-side method is the canonical one and, as an encouragement, only offer filters for it and not for the client-side method. However, on a technical level, there isn't a strong argument for not opening this up to client-side filtering (except, perhaps, for a concern of consistency), what with hooks readily available.

Trying to think more broadly about Gutenberg as the first-class editor and its role within WordPress, maybe it makes sense — borrowing terminology from React — to think of WordPress as a provider for the editor. Under that light, it would make sense to:

1. make the server-side method filterable, as WordPress's canonical registration method;
2. make the client-side method non-filterable, as a low-level interface for debugging/prototyping;
3. make a very thin "standalone provider" for Gutenberg, independent of WordPress and other backends, to be loaded with Gutenberg if one wishes to use the latter as a standalone editor;
4. within that standalone provider, leveraging hooks or something equivalent, implement a filterable block-registration interface with ultimately calls the low-level interface cited in (2).

[gziolo]

This one is stale and @youknowriad is working on a different set of changes in #6733. Let's close it and continue there.