In an effort to better understand all that is Gutenberg I’ll be doing a deep dive into the new editor in the coming weeks. I’ll be sharing what I learn as I go along from understanding the basics to developing custom blocks. I’ll be kicking things off with a look at the ideas behind gutenberg blocks.
What is a block
A Gutenberg block is the mechanism for creating complicated HTML output while maintaining modular edibility.
More simply, they are the way in which themes and plugins can add their own functionality and expand on the post editor.
The goal is to create a more unified experience for editing content. Rather than learning how to use shortcodes, manual HTML, etc, you can create all post content within blocks.
Block: The abstract term used to describe units of markup that, composed together, form the content or layout of a webpage. The idea combines concepts of what in WordPress today we achieve with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.
How are Blocks Made
Well a mommy and daddy block that love each other very much… I’m kidding of course.
Blocks are largely JavaScript based. Consisting of a call to the registerBlockType function to create and define the blocks features and functionality. As well as determine the structure of your block in the context of the editor and markup output when the block is saved.
Though when working with dynamic posts where the final markup can’t be determined at the time of the post being saved (such as a list of recent posts) PHP will come into play for displaying the final markup. While the JavaScript markup could represent fallback content or be unused.
The Block Object Tree
While editing a post with the Gutenberg editor, block information is stored in memory in a “tree of objects”. It isn’t HTML. A Gutenberg post could be represented as an object tree such as this:
[
{
type: 'core/cover-image',
attributes: {
url: 'my-hero.jpg',
align: 'full',
hasParallax: false,
hasBackgroundDim: true
},
children: [
"Gutenberg posts aren't HTML"
]
},
{
type: 'core/paragraph',
children: [
"Lately I've been hearing plen…"
]
}
]Editing Blocks
Where things really get interesting is how Gutenberg handles the conversion of the HTML markup output back into editable blocks in the editor.
Were the tree of objects and the final markup stored separately there would be the risk that they could become out of sync.
This is done by the use of HTML comments which are used to denote blocks in the post markup for conversion back to editable blocks in the editor.
A typical block comment would consist of an identifier for the block and a JSON literal storing all of the block attributes and information needed to make the block editable once more.
The Gutenberg Handbook goes into much more detail on why the decisions to use HTML comments was made and the benefits as well as potential downfalls of the process.
<!-- wp:image -->
<figure class="wp-block-image">
<img src="source.jpg" alt="" />
</figure>
<!-- /wp:image -->Even without Gutenberg the output is still valid HTML markup and can be rendered by the browser.
A purely dynamic block on the other hand may look like this:
<!-- wp:latest-posts {"postsToShow":4,"displayPostDate":true} /-->Wrapping Up
That’s a look into the basics of what a block is in the Gutenberg editor and how the data is stored transformed for the output vs the editor.
