The content format
a.k.a. the language of Gutenberg
HTML comments wrap around blocks and semantically enhance content. They can carry block attributes, or just serve as boundaries that don’t compromise block contents. See: The Language of Gutenberg, co-presented with Matías Ventura.
The block API exposes
registerBlockType (client) and
register_post_type (server) to create new blocks. Blocks have attributes which may be sourced from the content or from post meta. A block type’s
edit methods use these attributes to store content and render it in the editor. Block authors have many reusable components available in
wp.components.*. See: Creating Block Types
wp.element.createElement). Abstractions such as
.BlockControls allow the edit method to render components to multiple areas of the editor in a single return value. See: Block Controls
When declared on the server, block types can specify a
render_callback function that will be called on rendering the front-end, allowing blocks to be dynamic. See: Creating Dynamic Blocks
Block types can be intercepted via white- and blacklisting or via enhancement. See: Extending blocks
The block API’s transforms and deprecated constructs provide paths for moving pre-Gutenberg content to blocks and for letting blocks evolve, respectively. See: Deprecated blocks.
The plugins (
wp.plugins) and data (
wp.data) APIs allow a world of customization of the editor and follow the programming patterns of core Gutenberg, based on modularity and reuse of composable primitives. See: Extensibility (handbook), Riad Benguella’s Extensibility Workshop material, Riad’s “Dropit” Image Search and Drop plugin.
Block templates are arrangements of blocks that can be used as default empty states when adding a new post of a given post type. Locking levels optionally prevent deletion, movement and addition of blocks into a post. See: Templates
Aside from core validation mechanisms (block shape, template shape, “use once” blocks, etc.), the editor can be extended to provide domain-specific business logic at the block and editor levels. See: “Use once” validation
- One render function, multiple render areas with the Slot/Fill API
- Automatic contexts, e.g. selection-aware blocks that render conditionally
- Dogfooding sensibly, using the public interfaces as the canonical ones
- WordPress as the framework, offering its own primitives and components