Problem

Gutenberg (The WordPress Block Editor) doesn't have a proper server registry for blocks. This makes it difficult for decoupled applications to interact with blocks in any meaningful way.

This issue was created to start conversation around what a specification for Server Side Registry for Gutenberg blocks might look like.

Goals

This is a WIP, but some goals off the top of my head:

• Allow Gutenberg blocks to be registered in PHP, enabling the WordPress application layer to know what blocks are, and allow APIs such as the WP REST API, WP CLI and WPGraphQL to interact with blocks
• Allow Introspection for blocks (REST API, CLI, WPGraphQL)
• Introspection should include full description of blocks, so that any remote client can render a block from the description (i.e. Inner Block support needs to be described on the client)
• Enable server validation of blocks (currently Gutenberg only has client validation)
• Blocks should be registered globally (much like registering scripts or registering post types) but should be able to be associated with different editorial contexts such as different post types (much like enqueueing scripts or setting a post_type to show in the REST API, or the admin).
• Block attributes, fields, meta need to be strongly typed. No "object" or "array" Types.
• Gutenberg blocks should store a unique ID in the database along with the block data. This likely needs to happen in Gutenberg core, not as a spec definition, but it will allow Blocks to be interacted one at a time. Features like block-locking and collaborative editing can be enabled, but only if each block can be uniquely identified by multiple clients.

Prior Art

• Gutenberg Fields Middleware
• ACF Blocks
• Genesis Custom Blocks