Gutenberg is guten ready: embracing the WordPress block editor
Gutenberg, a new block editor for composing rich content, was merged into WordPress core in December 2018. It wasn’t really ready yet.
That’s a pithy way to hint at a problematic launch and to acknowledge that you may have heard some negative mood music about Gutenberg before now. That done, let’s move swiftly on and state the case for fully embracing this new editor in 2021 and beyond. Gutenberg has come a long way in three years, as have all good WordPress developers. We’ve stepped boldly out of our comfort zones and learned a lot about the technology that underpins the new interface. We’ve learned to think differently about how a WordPress site should be engineered, having been bestowed new powers. Powers for implementing a component-first methodology. And our recent clients have learned first-hand that this new interface brings them huge benefits.
Life before Gutenberg
Before we extol the virtues of managing content with blocks and developing websites around them, let’s get the lay of the land. Until recently, there were three or four key tools that defined our editing experience: TinyMCE, Shortcodes, ACF and Page Builders.
1. TinyMCE
The previous cornerstone of content management in WordPress, TinyMCE is a rich-text editor. A solid tool for formatting our copy, not so slick once you start trying to shoehorn images and suchlike into the document flow.
2. Shortcodes
We could extend the old editor with shortcodes. These are (the clue is in the title) short bits of code which call a function, perhaps with some parameters declared, thereby allowing us to specify a type of content to display in place. Plugins often brought their own to the table, so we could access their features. Imagine that you have WooCommerce installed and you want to display your featured products somewhere within the content of a page. In the editor you could drop this in:
[featured_products per_page=”6″ columns=”3″ orderby=”date” order=”desc”]
Even without any programming experience, you can probably parse this snippet of code and get the gist. But using these shortcodes wouldn’t come naturally – you’re going to need to refer to some documentation to know what is available and how to request it. WordPress founder Matt Mullenweg refers to this sort of thing as ‘mystery meat’.
3. ACF
Most WordPress developers would as soon install ACF as look at you. Advanced Custom Fields makes it easy for the developer to sprinkle some pre-prescribed input fields into the editor interface. These fields would accept data that the corresponding template file can ingest and then output in specific places on the resulting web page. We might even have leveraged the Flexible Content field in ACF, so that the user can build up their page using a handful of these fields, arranged in any order. In effect, we were creating a pale imitation of a block-based editor in this way.
Not bad, but an incomplete and inconsistent experience, and it obscures your content from Yoast. There’s a lot more work involved to mitigate this and save your SEO.
4. Page Builders
Ah, the elephant in the room! Many people use far-reaching page builder plugins (Beaver Builder, Elementor et al) to author their website in an approachable drag-and-drop way. With established solutions like these, why bother with Gutenberg? Well, because page builder plugins tend to be:
- Bloated. The somewhat tortured ‘div soup’ that gets served to the user is often a deeply nested tangle of unsemantic elements, offering poor performance, accessibility, and SEO.
- Proprietary. There’s some uncomfortable vendor lock in involved once you start to use one of these third-party tools. Gutenberg, however, is native to WordPress and open-source. It will not just follow the progression of WP over time, but actively shape this evolution.
- Inflexible. Despite their best efforts, in practice, it’s often impossible to precisely replicate a bespoke design layout using a page builder. A huge problem when your project has a pre-defined brand identity and some well-considered UI/UX design behind it.
- Buggy. Everybody’s fav.
You also need to consider integration with other software – will ‘x plugin’ that your project needs fully support the page builder you’re using? Yoast, for example, does not have great compatibility with page builders. They are prioritising Gutenberg integration, just as you’d expect considering that it’s the default WordPress editor. Accessing all of Yoast’s features helps you to maximise your SEO impact without manual duplication of effort. An editing solution that doesn’t play nicely with this plugin would be considered a deal-breaker for many.
If you’re short on time and money and enjoy DIY, a page builder is a great way to throw together a basic website with a safe and generic look. For something with more specificity, scope, and ambition, they’re just not the way to go.
Throw a block party
The point of this new block editor is to improve on all of the above and further the WordPress cause of democratising publishing (yes, the name Gutenberg refers to that 15th century printing press guy who effectively changed everything). If all content exists as interchangeable blocks, to be dragged and dropped in a more fluid and visually consistent interface, users with no technical knowledge are empowered to compose diverse layouts of content.
The editorial freedom that Gutenberg offers to site owners and content creators is huge. Having real flexibility in what you present on your web pages is particularly valuable to projects that expect to evolve, and can’t afford to paint themselves into corners. Businesses should seek to learn from their web analytics and adapt their offering over time according to this feedback.
Not only does the user have far more options for authoring their content, these options are also far more discoverable.
“Gutenberg is built on the principle of direct manipulation, which means that the primary options for how an element is displayed are controlled in the context of the block itself. This is a big shift from the traditional WordPress model, where options that were often buried deep in layers of navigation menus controlled the elements on a page through indirect mechanisms.“
As we move towards full-site editing (eg. controlling global elements such as the header with Gutenberg, not just page content) themes will become nothing more than stylesheets, as all functionality is based around the block ecosystem. More good news, as this makes the ‘instant facelift theme-swap’ realistic, even if your site is complex. It also means that users need only learn this one interface – we can stop traipsing around the admin looking for where and how to control our widgets, for example. That kind of thing will be consolidated. Developers can always take extra measures to support less confident users by simply limiting which blocks are available and by utilising features like block patterns and block templates to give them a head start when creating new posts.
In fact, on the subject of learning your way around just one interface, we could end up seeing something really ambitious. This project has the potential to establish WordPress as ‘the digital assets manager of the web’, to quote Leonardo Losoviz. He is referring to the concept of Create Once, Publish Everywhere, wherein the content you create in one application could become the single source of truth for dissemination to other platforms, in a medium-agnostic format. Gutenberg’s independent ‘blobs’ of data, more readily available via APIs, are helping to make WordPress to become a more compelling ‘headless’ CMS choice. For the uninitiated, this is about decoupling the data layer from the presentational layer of your website. It’s the new hotness. WordPress could take huge strides in this emerging space, with so much backing, community, and usership behind it.
We React to change
Let’s take a quick peek under the hood to get a sense of how this is being realised. Gutenberg introduces the flexible React.js framework into the mix. Many long-serving PHP developers in the WordPress ecosystem, with an established workflow and bag of tricks, have faced a steep learning curve. But the benefits of working with this technology are quickly felt, as it better facilitates the emerging requirement to modularise our codebase into self-sufficient, reusable components. If an element, such as a button, is less context-specific, then it can be shared (as a block) everywhere on the site. Bug fixes, enhancements, or design adjustments made to that one component get applied everywhere, consistently. A system of such independent blocks can greatly reduce duplication in the code base. This makes for leaner code and reduces time wasted repeating oneself in development.
Using React helps move the platform into step with the general web industry trend towards modern javascript frameworks, and towards supporting the atomised ‘headless’ paradigm we mentioned earlier. This is less about traditional monoliths and more about having tasks distributed to specialised services via APIs and frontend JavaScript. A developer conversant in the new WP tech stack is much better placed to navigate this landscape, with new transferable skills to match their new transferable code.
All aboard
With Gutenberg taking root, we’ve seen a fundamental shake-up of the platform with great advantages for authoring content and managing a codebase. We’ve seen that the project is not ‘finished’, and that’s great, there’s more pay-off still to come. But our argument, for anyone unsure about where WordPress stands right now, is that the block editor is ready – you can board this train now, knowing that any gloomy tumbledown station stops are behind us and it’s all enchanting vistas from here on out.