The Anatomy of Gutenberg Blocks in WordPress

The WordPress development community has been busy talking about Gutenberg blocks lately. If you’ve been keeping up to date with the latest WP development trends and topics, you may already have heard a lot about custom blocks development. But what exactly is a Gutenberg block? In this article, we will learn more about the anatomy of Gutenberg blocks.

But before going any further, lets take a moment to revisit what Gutenberg is, where it ties in the current WordPress scenario, and how is it different from the regular TinyMCE editor.

What is Gutenberg?

Gutenberg is a new approach to content creation and editing in WordPress. So far, ever since its inception, WordPress has been using the default TinyMCE content editor. While it has worked really well for most use cases, newer projects have offered a more nimble and faster content editing experience. Some examples would be the Medium editor, or the Ghost editor.

gutenberg block editor

Gutenberg attempts to offer a faster content editing experience to users. You can now insert custom content blocks, such as testimonials, drop caps, shortcodes, and more. All of this can be done directly within the editor itself — the interface is clean, minimal, and you can preview your changes right away.

Learn more about Gutenberg here.

Alright, we now know that Gutenberg makes life easier for WordPress users and content editing will be fun again. But is that all? How exactly is development for Gutenberg any different from what we have seen so far?

The answer lies in the way the new Gutenberg editor operates. In order to fully understand the use and importance of Gutenberg blocks, we need to know how Gutenberg works.

Gutenberg: Modus Operandi

So far, using the default WordPress workflow has been simple for developers. Here is how it works:

  • The user can type his or her content in the visual editor, format it as needed, and publish the post.
  • The editor then parses the visual editing into HTML. When the post_content() function is called to display the post on the frontend, HTML code of the content is returned.
  • The backend, therefore, is pretty much static. You get the visual and the HTML editor to work with. The post output is always returned in HTML. End of the story.

Gutenberg starts with some of the same basic ideas. It needs to return HTML in order to display the post content on the frontend. But this is where things get a little more interesting. Gutenberg blocks can have custom options — text color, highlight color, specialized formatting for blocks such as testimonials (say, a different font), and so on.

<!-- wp:atomic-blocks/ab-profile-box {"profileName":"Mike McAlister","profileTitle":"Designer","profileImgID":28,"twitter":"#","facebook":"#","instagram":"#"} -->

The solution is simple: the frontend is built on the basis of HTML output returned by the function. But Gutenberg also adds special comments related to the backend on the basis of the frontend, as seen in the snippet above. As such, the backend does not exist like a static word processing tool — instead, it is built on the go by Gutenberg on the basis of the post content’s HTML.

So now we know how Gutenberg works with your content, but what about Gutenberg blocks?

What are Gutenberg Blocks?

Simply put, a Gutenberg block is an entity that holds a chunk of content. This content can be in the form of anything, really. We have blocks for paragraphs, blockquotes, images, videos, and more. Unlike the TinyMCE editor that worked pretty much like a word processing software, Gutenberg views everything as a block. This allows developers to create customized plugins for special Gutenberg blocks.

gutenberg blocks

A look at how to add blocks to a post.

But it doesn’t stop there. Eventually, Gutenberg blocks will not be the only blocks in WordPress. Instead, the concept of custom blocks will evolve to include everything. In other words, even widgets, menus and headers can be viewed in terms of blocks in future versions of WordPress.

But for this discussion, we will focus entirely on Gutenberg blocks.

Now that we have established what Gutenberg blocks are, let’s take a look at what’s under the hood of Gutenberg blocks to further understand how they work.

The Anatomy of Gutenberg Blocks

Gutenberg blocks rely on JavaScript files that typically contain three main sections:

  • A block attributes list
  • An edit function
  • A save function

The edit function tells us how the block will look in the editor (on the backend). The save function, on the other hand, tells us how the block will look on the frontend. Once again, since Gutenberg generates the frontend output in HTML but adds special thought to backend appearance, both of these functions are very important.

We will now discuss each of these components of Gutenberg blocks in a little more detail. In subsequent posts on the Atomic Blocks blog, we will be learning how to create a Gutenberg block. In these posts, we will talk about the exact usage and more detailed description of these components. For now, let us just gain a basic idea of what these components do.

The List of Block Attributes

Pretty much like any other piece of code, Gutenberg blocks also work by means of attributes. An attribute defines what the given block does and what fields can be given to the user to edit the block.

The general syntax of an attribute is as follows:

attributes: {
        att-name: {
                type: 'type',
                source: 'source',
                selector: 'selector'

As we can see, every attribute should at least have three things:

  • Type: This defines the type of attribute that we are talking about. In most cases, you would want this to be “array”. In certain cases, say when you wish to work only with numbers, it can be a number, string, and so on.
  • Source: Defines the source of the given attribute. If the source of the attribute is a child element of the block, this should be defined as “children”.
  • Selector: Essentially, this will tell Gutenberg which child element is to be used here. In other words, what type of content is the given block going to handle? What does the HTML produced by this block contain? Is it heading text? Some code? Images? And so on.

A sample attribute declaration would look something like this:

attributes: {
        title: {
                type: 'array',
                source: 'children',
                selector: 'h2'

The above attribute simply defines the title of our Gutenberg block.

The edit Function

The edit function will tell Gutenberg how to show and work with our Gutenberg blocks inside the backend.

Look at the following code:

edit: function() {
        return [
            xyz( 'div',
                xyz( blocks.Editable, {
                    tagName: 'h2',
                    value: attributes.title,
                } ),

This is based on function declarations as made in the Gutenberg handbook.

In the above code, the edit function is telling Gutenberg that we have a title attribute (that we have already declared above). This title attribute will need an editable H2 field in HTML and if the title is already present, it needs to be shown in the editor. Simple!

Naturally, the xyz variable will need to be declared before-hand, much like any other WP development scenario.

The save Function

The save function deals with the output on the frontend. Here is an example:

  save: function() {
        return (
            xyz( 'div', 
                    xyz( 'h2', {}, attributes.title ),

The above function tells Gutenberg about the title attribute that we created. It needs to be displayed as an H2. The HTML will be parsed as:

    <h2>The title attribute</h2>


We have now familiarized ourselves with the anatomy of Gutenberg blocks. We now know what attributes are, and what is the role of edit and save functions in Gutenberg blocks.

Custom blocks can be used to display a wide variety of content in Gutenberg. Since it is still fairly new to the WP development world, Gutenberg has a lot to offer and by learning about Gutenberg blocks, you can get the most out of this fascinating editor.

You also might want to check out our Beginner’s Guide to JavaScript in Gutenberg post to learn a little more about how JavaScript ties into the new editor.

Posted by Sufyan bin Uzayr

Writer, web dev, coffee-lover. :)

Leave a Reply

Your email address will not be published. Required fields are marked *