Don’t Fear The Gutenberg (Just Learn How To Use It)

Reading Time: 7 minutes

With WordPress 5.0+ officially released to the public as of December 2018, it seems like the right time to be less fearful of the “G” word—the tool that must not be named.

Much like most change, the fear of the unknown is generally prevalent and understood, but we’re here to breed curiosity—a curiosity that ultimately breeds familiarity, and a familiarity that eventually eases fear.

Let’s say it together, “Gutenberg”.

That said, if we’re being serious, it’s the WordPress Block Editor, and it’s here to stay.

In first getting familiar with the Block Editor and understanding the response the community has had around it, it becomes more clear why this new feature is such a large transition, what benefits it ultimately provides in the grand scheme, and if it’s the best solution to adopt now or rather take stepping stones towards.

What is the Block Editor?

The WordPress Block Editor is Automattic’s response to the traditional WordPress pre-5.0 problem of rigid templating and limitations within that admin dashboard for inputting content within those templates. There were certainly already mechanisms already in place to solve these problems to some degree. But the paradigm that the Block Editor’s name aims to convey really tries to improve the user experience and performance of the sites that choose to work with it.

The Benefits

Convenience + Flexibility: Movable, Configurable and Reusable Blocks

The Block Editor now provides WordPress with a large system of core Blocks with their own individual set of settings, inputs, and toggles to be configured in all sorts of colors, alignments, and types of content.

It also provides the opportunity to extend this system of blocks to include any custom blocks that a theme developer, plugin developer, or a user installing those said plugins can integrate into the larger set. Each page of blocks can be rearranged through a drag and drop interface and adding additional blocks or removing unused ones is quite intuitive.

Further, it introduces a mechanism to be able to add a block, populate it with specific content (a title of “Benefits”, description of a specific block of text and an image—for example) and then set that block as a Reusable Block. This specification allows this “Benefits” section with the same title, description of the first page to then be reused as is onto a second, third, or even fourth page.

Anytime an edit is made to one, the same edit is applied to the others of the same Reusable Block. With this particular setting not enabled for a block, any new contents can simply entered for that individual block rather than carrying over content from a different page.

Expediency: Marketing Landing Pages

Once a theme is set up to use a system of blocks designed for it, those blocks can be used on practically any page that has the Block Editor enabled.

This allows for any content manager to go in and add or manipulate any of the theme’s blocks on a page. So, whipping up a landing page for a particular marketing campaign can be super easy without requiring a developer to design, develop, and deploy a new page. As long as the blocks and structure needed already exist on another page using the Block Editor, they can be used on any page.

Site Performance: Post Content vs Post Meta

In becoming more familiar with the core Block Editor and its way of storing and handling any content that is inputted by the user, it becomes more clear that the Block Editor is fundamentally more efficient in terms of overall site performance. The resources do not need to work nearly as hard at fetching data from the database, nor is as much time put into parsing that data and displaying that data within the browser.

This performance enhancement ultimately comes down to where and how the content is being stored by the Block Editor when new data is saved.

Traditionally, the actual data input by a user would be stored as post-meta, which means that each individual entry—whether it was a selected background color, the text within a button, or the link to that same button—would need its own line of reference within the database.

With each added line within the database referring to each piece of post-meta, each page load (without the use of more technical site optimization tools) would prompt the need to retrieve all those lines within the database, requiring additional processing to handle that data and display them where needed, embedded within the other lines of code that may be applicable.

The Block Editor’s core intent strips down the number of database requests that need to be made in order to retrieve content by storing, more or less, a single reference to the page content.

What are the hurdles?

Now with that in mind, Automattic (and ultimately WordPress) did not pioneer this paradigm of being able to use a page builder in WordPress as a means for non-developers to create or edit a website.

For those immersed in the world of WordPress, it’s no surprise that this way of thinking of individualized blocks that can be added through the admin dashboard, configured and rearranged is not a new concept. Many plugins and themes have already made many site managers and developers aware of this particular way of content management—many of which have previously been able to adopt some form of this system.

But if that’s the case, then what’s the problem and where does the fear of the Block Editor come from?

Community Response

Issue 1: Deterrence From The Predecessors

As previously mentioned, many plugins and themes have already grown awareness around Block Editor’s general paradigm of reusable and flexible blocks. While the overall concept of flexibility is where the site-building community is moving, the general execution of these tools may have not provided the friendliest introductions and unfortunately, some of these predecessors (arguably still contemporaries), have built some bad blood in and around the developer community.

Plugins like Visual Composer, WP Bakery Page Builder, or Divi Builder have deterred many developers by creating tools that often feel more like something to be fought against, rather than worked with. Many of the features of these tools and ways of extending them (if possible) often come off more as bloat, and the user experience—given the number of available customizations—often appears to be overwhelming.

These plugins often introduce a large set of styles and visual cues that deviate from what the average WordPress user is likely familiar with. It’s clear that a foreign system is being overlaid onto the existing WordPress infrastructure. These alternatives are in some ways so configurable that there’s now a new challenge. It’s so easy to complicate.

On the other hand, with Block Editor as part of the WordPress Core, the overall feel of the editing interface matches the overall tone of the rest of the dashboard. It doesn’t feel like it is being shoehorned into the equation to achieve the results it provides.

In this instance, Automattic has done a good job in making the editor not feel invasive from a user editor’s perspective. Ultimately, the challenge of being so configurable that it becomes convoluted could still be an issue. So, doing that balancing act of how much control an editor should have always needs to come into question.

Issue 2: ReactJS vs PHP

With WordPress being a more traditionally PHP platform, the shift from a predominantly PHP templating system to a more psuedo-Javascript based system (in the form of ReactJS) is where some of this hesitation is likely to stem from.

WordPress developers have made a living by understanding PHP as a mechanism to structure logic that displays content in a dynamic way. And Javascript is a way to interface and interact with the data and content that’s already present—in some ways also using Javascript to dynamically load content in after the fact that PHP passes through to it. ReactJS in many ways turns this idea on its head.

That said, it’s not just a paradigm shift into flexible blocks. It’s also a shift into an entirely new language and framework for a lot of folks adapting to this new system. Despite the learning curve that Gutenberg presents (which is certainly outside the comfort zone for many), it is encouraging developers to start getting familiar with the new system as it’s certainly going to be the future of WordPress development.

Issue 3: Content Integrated into the Code

As mentioned previously with regard to the Block Editor’s benefits, the storage of content within page content rather than page meta ultimately is a huge bonus in the realm of site performance.

Unfortunately, this benefit comes with an added issue identified within the developer community. In this new paradigm, the HTML markup (code) that wraps the content being displayed—which is traditionally thought of two separate entities—poses a challenge to developers and site managers that would likely require the ability to make a larger sweeping change throughout the site.

Typically, to fix a structural element of a template it would be as simple as going into a template file (that’s, say, used to display each individual blog post) and simply add in that closing HTML tag that was missing. However, with the HTML markup and content being saved together within the database, any structural changes that need to happen to any blocks that may have a missing necessary tag would need to be pulled up on each page that it’s being used on the dashboard and then resaved. This is a very simple task if it’s one or two pages, but a large scale site with that element being used throughout could pose an issue, or require some database manipulation.

Now, if it’s so tedious, then why is that the case?

In pondering the same question and taking a look at how Automattic has addressed it, the reason is around consent. Aside from the speed performance benefit, needing someone to go in and resave content ties into that concept of consent because that editor is aware that changes are going to happen and is consenting to that change affecting that page by hitting that save button.

Adopt Now or Take Baby Steps?

Having assessed the valid concerns of the community, the ultimate question comes down to whether it’s time to adopt immediately to the Block Editor—ReactJS, markup/content melding and all—or make smaller steps towards adopting it. On the other hand, there’s always an alternate option of ultimately not upgrading to the Block Editor, installing WordPress’s legacy Classic Editor plugin. Of course, the latter is likely just postponing the inevitable.

With the luxury of time and an open budget, taking the time to adopt to the Block Editor in all its glory could be in the best interest of a company, but with that community concern of content bound too closely with markup, a full adoption may be jumping the gun for some.

Advanced Custom Fields: A Lower Barrier To Entry Stepping Stone

If that last concern is a dealbreaker, fortunately, the Advanced Custom Fields plugin team has anticipated the need to catch up with the new Block Editor system.

They have provided a middle ground to this stark difference in how code and content are managed while still adapting to the core principles of the Block Editor and ultimately using the interface of the Block Editor. It’s a system that still does use PHP but gives some space to use ReactJS where desired, and is an extension of a system that’s quite beloved already by the WordPress developer community.

With Advanced Custom Fields being an already beloved tool for providing ease in creating more intelligent and flexible templates, the ACF team has been one of the tools to adopt the Block paradigm and provides many of the same benefits while still being a lower barrier to entry. Though having already previously implemented a Flexible Content field as one of the options to creating more flexible drag and drop layouts, in retrospect it’s clear that the Flexible Content field was simply a stepping stone to Core’s new way of thinking in Blocks—another indicator that this paradigm was the natural progression and ultimate next step for WordPress.

Either way, with or without Advanced Custom Fields, there are certainly ways to get familiar with Gutenberg rather than shying away from it(and thereby possibly accumulating technical debt in the process). Gutenberg (or The Block Editor) is here to stay, and the WordPress open source community is bound to keep on improving it.