In December 2019, WordPress rolled out version 5.0, introducing a new approach to editing and managing content. When the block editor was in beta in the fall, we decided it would be best to embrace this new approach and work quickly to integrate it into our process, development and design approaches. Although change is terrifying, and the editor was buggy, we saw a lot in the block editor that we liked, and that aligned with our thinking on how to build websites.
WordPress has grown up and turned into a real CMS
Way back in the day, WordPress started as a blogging system, but has since become a general-purpose CMS. This new block editor is an expression of WordPress developers acknowledging this change and adapting to meet the new needs that arise from it.
Instead of a single text area where you just type your thoughts, WordPress 5.0 has created a free-form approach which thinks about a page as a series of blocks of content. Blocks can be headings, paragraphs, tables, images—or any combination of those things. They can also be fancier—like a block of blog posts or a big cover image. Basically, all the building blocks of a modern website.
First impressions
If you’re interested in our first impressions, you can check our blog post about Gutenberg. But TL;DR, here’s a lightning round of what we thought:
- Editing things in place rules! Instead of running around all over the back-end to edit disparate pieces of content, we can (for the most part) edit things in place.
- Blocks are way more discoverable—they show up in a nice big drop-down panel.
- Breaking things down into blocks makes them easy to reuse over and over again. For example, turning CTAs into “reusable blocks.” It’s easier to build up new pages, without relying on tailor-made pager templates
- We are done with shortcodes, which were always fragile and also an abstract way to work in the back end. They’re hard to train a client on—especially if you’re not comfortable working with “code.” Now they can use these things without fear of them breaking.
Not gonna lie—switching to the block editor was a big learning experience on both the front and back-ends of a website. But framing it in an optimistic way, and trying to understand the philosophy behind it made us more keen to dig in.
How we feel now
Are things still as rosy now as they were a year ago? Yup!
We’re all in on blocks
We are depending more on built-in blocks for layout than we’d ever imagined we would—a lot of which are the default blocks that WP provides. We have been thinking about how we can work smarter and not harder and use existing blocks and create the effect that we desire instead of making something brand new each time. For example, we would much rather use columns and put the image and text side by side instead of building a specific block for that type of layout.
Aside from these regular blocks, we’re also exploring with reusable blocks, custom blocks that we design for the needs of the project using ACF Pro, and one other multi-purpose block that gets a lot of use, which we’ve named (oh so creatively) the “Kobot Formatting Block.” It lets us contain groups of content into a container which will have a class applied to it. Any content within that container can be giving special styling and behaviour.
Working within the system
We asked ourselves, instead of adding another layer of code and functionality, why not work closer to the actual WordPress app?
The block editor has a lot of functionality and flexibility in its block system—enough to cover most of what you need for most websites. And now there are tables (Jodie is a big fan of this one)! And the image galleries don’t suck either (And Bryan quite likes this one).
Also, if you change themes, everything should degrade nicely! Creating custom stuff or using many plugins may be a way of taking on technical debt. Using the simpler, built-in tool means that we take on less of it. This means that website maintenance and eventual upgrade will be easier (changing to a new theme, expanding a website, etc.)
Extending the system
WordPress has a stylesheet to define all these base styles for all the blocks. We have a stylesheet in our starter theme that has all these styles, which we use to overwrite the default Block Editor styles as needed. Since we have been using CSS grid for some projects, this gives us the opportunity to integrate this into some of the new blocks which still use flexbox for positioning.
Where we do get custom is in our use of Custom Post Types. In places where we would have used shortcodes before, we’ll define blocks instead. These blocks have options that are much easier to understand for example: layout needs, number of “posts” to pull in. maybe here we put a screenshot of a block with all the options
Our wishlist
As much as we stand by our (perhaps controversial?) love of this new editor, pobody’s nerfect! There are still some places we see room for improvement.
Modifiable blocks
The ability to add options and functionality to existing blocks would be a huge bonus. It’s hard to modify the blocks for our purposes in this editor. And sometimes by the time someone has written a blog post about it or you’ve figured it out they’ve gotten rid of the way it was.
So, for example, adding a dropdown where you could have a list of theme-specific classes on blocks would be great. Of course you can add classes in the Advanced section, but this isn’t super evident or has no means to maintain consistency or repeatability.
No-nonsense columns
The columns blocks are great but it would be nice to have the ability to easily offset the blocks so they aren’t equal sizes. The irony is that the block editor stylesheets have classes to do this, but you need to manually add them.
Saveable blocks
A great addition to the block editor’s functionality would be saveable block—sort of like the existing reusable block, but more about formatting and internal blocks.
When we’ve formatted blocks with a specific styling (e.g., H2 etc), some people have been saving them as a reusable block and using it almost as a content template. If this could take the form of a “block template” or similar, it would be possible to use it in place of a CPT for something simple like a staff page!
(Clearly, we’re geniuses—Call us, WordPress!)
Spook list
As much as we like it, there are still a few things that scare us.
WordPress is old but the block editor is still very young. From the development side, over the last year we’ve already encountered enough code that is deprecated to put a scare in us. And along with that, the developer documentation is pretty poor. It’s super easy to hack on PHP WordPress but super hard to hack on core block editor blocks.
We don’t know React very well, so we can’t easily build fully custom blocks, still very dependent on ACF Pro to build out our custom blocks. Plus, our blocks are mostly not WYSIWYG, which is a little weird, and maybe disrupts the editing flow.
WordPress is moved towards being more like a Squarespace back-end, where you can drag stuff anywhere and nest things, etc. This can be a liability with locking down the layout and design of a page to prevent the site owner from inadvertently breaking the layout. But, like many things, this issue has 2 sides. Because it also empowers clients with even a casual knowledge of how it works to update and build things on almost the same level as we do.
…
After a year of working with the block editor, we’re feeling pretty comfortable with it. We are glad that we embraced it early because we’re starting to see the rewards of that already. Our development process is moving much quicker as a result and the back-end experience is much stronger than it was before. The block editor is much clearer to the site administrator than our old approaches which required the use of shortcodes, sometimes with complex formatting. Our documentation for the client can also be lighter because we can lean heavier on the clarity of the interface as well as inject our own prompts within that interface, bringing instructions out of the manual and into the place (and time) the client really needs it.