Published

I count myself among the crowd that resisted and rallied against the inclusion of The Block Editor (aka The Gutenberg Editor) as WordPress’ default editing experience. But after digging deeper into the weeds I have to admit I think I’m coming around. Sort of.

I⁠’ve been dead set against drag-and-drop page builders in the WordPress ecosystem ever since Visual Composer first stepped into the room. Part of it is attributable to “Cranky Old Developer Syndrome” but I also worried about giving my clients too much power. In my mind I envisioned pages adorned with Comics Sans MS replete with garish colour choices which would inevitably end up with them requesting us to “fix” said page.

Our clients already have a content workflow that involves targeted use of Page Templates and Shortcodes which has so far been enough for their day-to-day editing needs. If they lacked for anything we knew they would get in touch with us anyway.

But we couldn’t deny that page builders could roll out new layouts in a fraction of the time. So as with all things new we experimented with several page builders before finally deciding on Elementor which at that time I considered “the least bad of the lot”. Yeah, I still wasn’t a fan of page builders but we used it sparingly when we felt they could really provide an edge.

Then WordPress stepped in with their own official page builder named “Gutenberg” aka “The Block Editor”. Most of us saw dark clouds on the horizon fearing that those steering WordPress were fixated on a direction many of us did not like. When WordPress 5 released and made The Block Editor the default editing experience, we immediately installed the Classic Editor plugin on all our websites. We expected there to be teething pains and were not ready to roll this out to our clients yet.

We did play around with The Block Editor in those early days but it gave us no reason to use it over existing page builders. The interface alone was rather cumbersome and we had a heck of a time locating the settings we were looking for. We left it aside to incubate a bit longer hoping that time would eventually make us take notice.

I honestly think this bird is now ready to fly. But before that, let’s be real about a few things:

  1. The Block Editor is here to stay. WordPress has made this abundantly clear and those who don’t want to or cannot get on board really need to look for alternatives. As of typing the Gutenberg plugin has overwhelmingly negative reviews (2.1 stars out of 5) and given how badly WordPress leadership has been behaving lately, this might be a good time to jump ship.
  2. I am not trying to convince anyone as to the efficacy of The Block Editor. We all find ourselves in different situations and it’s clear from the outcry that The Block Editor is not to everyone’s taste. YMMV.
  3. The landscape of websites and web applications has changed and is continuing to evolve. As popular and useful as WordPress is it is not always the best choice. You may have to build a bespoke application using one of the many frameworks and libraries available today.

So with that in mind, my take is that The Block Editor is now mature enough for it to be of value to our clients particularly since the addition of the theme.json file in v 5.8 and Full Site Editing in v5.9.

WYSIWYG content editing

I’m old enough to have used WYSIWYG editors (“What-You-See-Is-What-You-Get”) in the early days of the internet and they really were quite terrible. They produced ugly code that rarely matched the actual output in the browser. It wasn’t entirely their fault since The Browser Wars meant that standards were not kept as browsers tried to do their own thing to get a leg up over the competition. But I knew that if these editors could give an accurate portrayal of what would actually appear in the browser then that would be a huge boost to usability.

This task is arguably easier today with a stricter adherence to web standards and a thinning of the browser rendering engines. The Block Editor does a really good job of showing an accurate result in the actual browser. The theme.json  file really does admirable heavy lifting here and, in my testing, anytime the output was different from the editor it was because there was a stray CSS declaration on the front-end.

Standardising Colours, Fonts and Sizes

We’ve found that one way to discourage clients from using awkward colours, fonts and sizes is to provide a standard set of acceptable choices that line up with the design. This can be achieved, again, with the theme.json file. This isn’t unique to The Block Editor as other page builders have had this as well but wouldn’t it have been strange if it’d been absent?

Providing defaults and the ability to over-write them

Building from the previous point, you could give all your headings a standard colour but then over-write it for one or more of them. You can do this for different Blocks including custom Blocks included with a plugin. You guessed it, all this is done from theme.json.

Helping Developers along

I think credit needs to be given to the Gutenberg team for really doing their best to help developers get on board with The Block Editor by making things as easy as possible for them. I mentioned the theme.json file in all previous points which means you can do a lot of stuff from 1 file.

That’s not all. If you want to build a Block Theme you don’t have to learn how to write Block-specific code. Instead, build the design in The Block Editor then copy the code to your file. It really is that simple and saves a lot of time.

But wait⁠⁠⁠⁠…

I did say I was “sort of” coming around. There are still definite pain points when using The Block Editor and here are some that I’ve experienced:

Ever-changing interface

It’s been 6 years since The Block Editor has been included with WordPress and the interface is still changing. And I’m not referring to the new features like the Font Library but the interface for things that have been there since practically Day 1.

Case in point: In mid-2024 we conducted our first “Block Editor” training to teach a client how to use it to update their website. 6 months later we are about to train another client to do the same and obviously wanted to re-use the slides but discovered that parts of the Block Editor interface had subtly changed.

Settings Placement

This point may be positionally contradictory to the one above but I’m aiming to air out grievances and not for logical consistency. Basically I feel where and how settings are presented to the user needs to be rethought because it is currently confusing.

I appreciate the challenge that comes with this task especially when the team has to cater to different screen sizes. I can understand why they settled on having the Settings in a sidebar but their presentation in the sidebar itself is confusing. First you have different tabs (one of which is called Settings) which each have collapsible sections some of which are not visible until first selecting from a hidden menu. It’s just not self-explanatory for most people.

And then there is the Block Toolbar which I thought would function much like the shortcut toolbar that appears above selected text in Microsoft Office applications: display the most often used settings but have all of them available in the Ribbon/Settings Sidebar. Instead, I could’ve sworn that some Block Toolbars display settings not available in the Settings Sidebar.

Troubleshooting theme.json 

While it makes sense to use JSON to control the theme it does make it difficult to troubleshoot typos and minor mistakes like stray commas.

The nesting of properties in theme.json  can be very deep so I hope your code editor can collapse sections. I wonder if there will ever be a way to split the JSON object into different files to make things easier to manage.

Documentation is good but could be better

My experience with the WordPress Theme Developer Handbook reminded me a lot of CakePHP’s Developer documents: I first got into both because their documentation was so much better than the competition’s. But as each grew in popularity so did their respective docs making them harder to navigate. Nearly all the information you could need is already in there but it’s just hard to find sometimes.

Documentation is a recognized weak point in a lot of software projects so I can empathize. Now this is the perfect role for Al: read the docs for me and get me what I need.

In which I embrace the new way to develop WordPress Themes

I am honestly quite surprised how quickly I took to The Block Editor once I actually gave it a chance and sat down to learn the ins-and-outs. It is becoming my preferred way to build WordPress themes and rarely does it get in my way (at least so far). But at the end of the day WordPress is just one of the tools I use and I’m always looking out for ways that will help me deliver better value to my clients.