How We Made Gutenberg Editor More Gut

Following its somewhat rocky start, the Gutenberg editor has revolutionized content editing in WordPress. Combine it with our open-source boilerplate, and you’re perfectly equipped to start building clean, fast, and reliable web solutions. 

First launched in 2019, WordPress’s default editor Gutenberg brought about a new era of content creation. By introducing the concept of blocks, it made website building easier for the users while also allowing for more flexibility and creativity in the process. 

To make the most of Gutenberg editor, over the years we’ve developed our own WordPress boilerplate. Block by block, we’ve put together a comprehensive development kit that makes building complex WordPress themes and plugins painless.

In this article, we explain how Gutenberg became what it is today, why it’s our platform of choice, and how you too can build custom web solutions fast and efficiently with the help of Eightshift Boilerplate. Let’s dive in.

To provide some background, here’s a brief history lesson on the evolution of content editing in WordPress.

When WordPress was first introduced back in 2003, its basic editor consisted of… well, the basics. A simple title, post category, short summary (excerpt), and the post content. Simple formatting options like bold, italic, and underline were also available, along with some HTML basics like images and blockquotes. A site’s theme was responsible for how everything looked, worked and felt.

The WordPress experience was expanded in the next couple of years with the addition of features like shortcodes and plugins. However, no major changes were introduced until 2012 and the launch of the Customizer. This allowed changing some aspects of a theme without modifying the code, and gave developers an easy way to use the API for all kinds of cool things.

The real power of WordPress’s plugin system came into play in 2018 when the first page builder plugins started to hit the market. Users could edit content in a smoother, more visual way without needing to write any code, and layouts could became more complex than the previous vertical blog-style ones. A well-known example of a page builder from that time is the WPBakery page builder, still being developed to this day.

In late 2010’s, the market was full of page builders. However, as for the editing experience – the Core never looked so stale. This changed drastically with versions 4.8 and 4.9 which revealed something new, the beginnings of Gutenberg editor.

A new, React-based editor ditched the text-like flow. The pages were now laid out as a collection of blocks – from simple paragraphs and images to columns, tables, or embedded content. Unfortunately, the initial versions were chock-full of bugs as the development team was working according to the “work fast and break things” principle.

However, after the initial teething issues, Gutenberg became the standard editor in WordPress 5.0 and has been continuously improved upon and cleaned up ever since. The sheer power of moving your editor away from the backend (PHP) into the frontend prompted developments like Full-site editing.

By the way, if you’re feeling nostalgic or just want a taste of history, you can install the Classic editor plugin on your site.

A perfectly valid question. Why use Gutenberg as our platform of choice since most other page builders offer ways of extending the base features?

The answer is rather simple.

As it turns out, when you build something really generic, it tends to get bloaty. You might not notice it when you’re adding content, but a lot of page builders add tons of unnecessary DOM elements, scripts, and styles. While there are ways of optimizing them, they are never as good as a custom solution.

There’s also a very important buzzword worth mentioning here – DX or developer experience. Trying to extend a page builder sometimes takes away from it.

Of course, it’s not all sunshine and rainbows in the land of Gutenberg. The initial versions were pretty buggy, some decisions questionable, and documentation lacking. However, after some time and polishing, it turned out to be a pretty solid platform, both to use and develop on.

We tried our luck with boilerplates even before Gutenberg editor was a thing. The first version of Eightshift Boilerplate was actually based on ACF Section Creator. 

ACF stands for Advanced Custom Fields; a plugin that allows defining custom metadata fields for various parts of your site. The ACF Section Creator was mostly a collection of helpers and presented a simple way of creating customizable sections so the users could easily build sites.

There was a problem, though. ACF had a tendency to seriously slow down your site if you had a certain number of custom fields. The editing experience was also a step (or three) back from the page builders of the time.

When Gutenberg editor became the norm, we were skeptical at first. However, after giving it some time and practice, we decided to make the switch and base our boilerplate on Gutenberg. Some ideas from our informal discussions at the time actually shaped the current version of our boilerplate. After we created the concept in 2019, the initial version was soon out.

Using a modern stack with technologies like SASS and Webpack, out-of-the-box linter configs and soon a Storybook support, we were off to a good start.

Core Gutenberg editor blocks are mostly what we call static blocks. The representation of the block (HTML + the content you added) is saved to the database as-is. This is a big advantage as you don’t need anything special to parse the data. You can just display the HTML on the front, and that’s it!

However, static blocks have certain disadvantages. Because they’re stored as raw HTML, the editor must parse that into something the React-based block editor can use. This is fairly simple for basic elements like paragraphs, but with any block more complex than that, it’s a nightmare. 

If you decide to make any changes to your blocks, the Gutenberg editor needs a way of migrating blocks from the “old” versions to the “newer” ones. This doesn’t always work and/or can lead to some unwelcome results on the frontend.

But fret not, there is a way, and it’s called dynamic blocks. Basically, instead of saving the raw HTML representation of the block, you only save the (data) attributes needed to display it. Everything else is handled by PHP on the frontend and React on the backend. The format used is very simple; it’s a modified version of HTML comments, called Block grammar in WordPress. It contains the block name, JSON-parsed attributes, and the ability to nest inner blocks, if needed.

We have other cool tools in our arsenal as well. For example, the Block transformer can do batch block updates and editing thanks to the simple structure of dynamic blocks (it’s not in Libs yet, though, but stay tuned).

And to finally get to the components part, they are our way of atomizing blocks and sharing things like typography and images, which can be standardized and re-used between blocks.

Components can also be used to separate tracking, footers, and similar functionalities only rendered through PHP. A block would mean nothing there as it’s meant to be placed in the WordPress block editor.

Wouldn’t it be wonderful if all your blocks and components had a single source of truth for everything? That’s where manifests come in.

Manifests are simple JSON files that define all the basics of a block or a component: name, attributes, common options and, in case of blocks, components contained therein. Things like CSS variables outputs, example data for block previews, or block picker’s icon and category, are also defined there.

Recently, we got a big confirmation that we were on the right track with this idea when the Core introduced theme.json to serve a similar purpose.

Besides block and component manifests, we also have a manifest for the theme itself. This is where we define what’s common to one theme, like breakpoints, the default font, colors, etc. It also contains some basic general options used by Webpack and some Libs internals.

The initial versions of our boilerplate used a flexbox-based grid, and most of the attributes that control block styling (e.g. font size) were output as classes. Together with a collection of SASS helpers, this was a pretty good solution.

In 2021, we got the chance to do something new. We were finally able to drop Internet Explorer 11, and the next big thing became fully available to us – CSS variables.

Version 5.0 of (frontend) Libs brought a major rework of everything. Adding something basic like a color option for a paragraph takes just a few minutes, as you only need a couple of entries in the manifest and a couple of lines of CSS. It’s magical!

We also changed our way of composing components and standardized the naming of attributes. To keep things consistent, all of the improvements were also reflected in the (backend) Libs.

With time, we collected a plethora of helpers, and with the addition of WP CLI (command-line interface) commands, we had the pillars of a nice developer experience.

If everything stated above isn’t reason enough to use our boilerplate on a project, let’s add some more benefits to the mix. Besides a modern tech stack and great DX, the Eightshift Boilerplate brings advantages both to your clients and teams. 

We are big supporters of focusing on the user experience and making digital products accessible to everyone, and these views are reflected in our WP boilerplate as well.

Every project is different, as is every client. With a broad set of building-block editor components, a huge icon set, and a nice collection of default blocks, you can make your blocks as simple or as complex as you want. Your users will fall in love with the process of filling in the content.

To make layouts easier, our wrapper system allows you to tweak the horizontal positioning of all blocks on a page easily, together with the basics like spacing, background color, and the borders around blocks.

In 2023, accessibility is no longer something that is nice to have, it’s a must. All of our base blocks are compliant with the WCAG AA level. Our goal is to make them even more accessible with time.

Awesomeness doesn’t have to stop at themes. We also have a plugin boilerplate that was used to create great things like Eightshift Forms, a block-based and ultra-powerful form plugin that we use.

All parts of our boilerplate are open source. Feel free to ask questions, report issues if you encounter them and, of course, submit a PR or two if you feel like it.

Having been developed for a couple of years now, the Eightshift Boilerplate proved to be a great base for themes. The Infinum web, probably the place where you’re reading this, is based on Gutenberg, and so are other popular sites like Productive, UK Safer Internet Centre, or D66. You can check the whole list at https://eightshift.com/showcase.

We follow all the trends, best practices, and modern technologies. Even though this might bring about unpleasant associations with the early Gutenberg editor, we put a lot of care into backwards compatibility and provide migration guides to make your life easier.

Of course, sometimes migration is not an option, but what better time to start a new theme!

The Gutenberg editor may have been off to a rocky start, but today it is a solid editor that offers a great level of extensibility. With a modern boilerplate to connect all the dots, developing for WordPress becomes pure joy.

While there will always be space for page builders, we strongly believe that the Gutenberg editor, powered by Eightshift Boilerplate, is the future of WordPress.