How and why we’ve embraced WordPress Block Editor
Written by Jonny Vaughan and Ben Rutland.
What is Block Editor?
Block Editor, colloquially known as Gutenberg, is WordPress’ page editor, using “blocks” to create content on web pages. Blocks can be anything such as paragraphs, links, headings, spacers and images. WordPress comes with many pre-built blocks, and some plugins come with their own blocks too, to make building a post or a page a unified editing experience.
Prior to its release in 2018, WordPress sites were built using its Classic Editor – a wysiwyg editor that is often accompanied by custom fields to create page templates.
We’ve been producing websites using Block Editor since its release and in that time we’ve learnt how best to harness its power for our client projects and how to avoid its pitfalls. But we know it’s a polarising topic with agencies – they are either fully embracing it or are sticking with Classic Editor solutions.
In our recruitment process over the last 12 months, we’ve found it challenging to find developers who have the necessary experience to build websites using Block Editor. There’s no doubt in our minds that this is the future of WordPress and its demand is apparent with our clients.
Why do we produce sites using Block Editor?
1. Editing experience for clients
The biggest benefit of the block editor is providing our clients with a consistent user interface for adding content and getting instant visual feedback. Previously, with Classic Editor, complex or functional content would be added by using shortcodes or custom fields which led to hard to read posts, and no visualisation of the published page.
Block editor has some useful controls for the editor to make drafting posts and pages simple such as:
- Drag-and-drop reordering
- Converting blocks from one to another
- Locking blocks in place
- Creating “reusable blocks” to be used in more than one post/page
- Grouping blocks
2. Plugin integration
Block Editor also has a standardised interface for adding and updating blocks. Plugins and themes can hook into the editor so custom blocks will extend the editor functionality without giving a disparate experience, unlike shortcodes which was the de facto way to integrate plugin content previously.
3. Configuration for brand consistency
The block editor uses a theme.json file which is essentially a configuration file. Colours and fonts are set in this file that blocks then “inherit” – a theme.json file might determine four font sizes and no ability to set a custom font size. An editor can then customise a block whilst remaining within the desired design criteria. This is a useful feature to “lock down” the editor and comes with a lot of options for configuring all blocks and individual blocks independently.
This configuration via Block Editor ensures our client’s websites adhere to their brand guidelines and provide design consistency by giving them enough editing control to produce engaging content.
What are the developer considerations when using Block Editor?
1. Tech stack
Prior to Block Editor, most WordPress developers would typically have stronger PHP skills than React/JSX. This has put off some developers from adopting Block Editor because it requires a change of skills which may not necessarily outweigh the benefits for them.
Patchy documentation about the WordPress core components which are used to build a block can be a difficulty to overcome as a developer. Documentation is improving but staying abreast of new WordPress releases and reading release notes is key.
There is more to consider when building a block than what is output on the front-end. Additional considerations include:
- Input fields (colour inputs, buttons, inner blocks)
- Sidebar controls (colours, typography, additional classnames)
- Toolbar (text/block alignment, bold/italic)
In order to create a unified editing experience between core and custom blocks, using the core WordPress components to build out a block is important, however it can be a long and challenging process to find which component will achieve what is required.
Support for advanced features such as padding and margin is limited (although improving in each new release) resulting in a hybrid approach of building blocks where some customisation is achievable but styling is still rather restricted.
4. Full Site Editing
In WordPress 5.9 (January 2022), a new way to fully edit all aspects of a WordPress site was released called Full Site Editing (FSE). Themes that support this allow users to edit all parts of their website using Block Editor (including headers and footers).
We have decided not to adopt FSE for our client projects because it opens up the opportunity to make substantial changes to a website that may not be desired. Our enterprise clients accept there is a fine balance between editing power versus editing control, and we tend to err on the side of control by disabling FSE. Headers and footers can be complex parts of a website incorporating menus and other features which are typically best left to developers to work on.
5. Advanced Custom Fields
The Advanced Custom Fields plugin (ACF) is a widely used plugin that makes it easy to add custom metadata to posts, terms, users and more. The plugin has the ability to easily create blocks that can add to Block Editor. These blocks, unlike those in core, are created with PHP instead of React improving the developer experience as it’s much quicker to create a block template in PHP and create the fields with ACF. ACF handles the data storage and retrieval of each field too which takes a lot of the burden off the developer.
Whilst ACF meets most of our requirements, there are still some pros and cons which were taken into account when we decided our approach with Block Editor:
Pros of using ACF for custom blocks
- Uses PHP instead of React/JS
- Uses REST requests to keep editing experience synced
- Block previews
- Custom ACF fields can be used easily
- Complicated conditional logic is simple to implement
- No need for a build step unless changing CSS/JS
Cons of using ACF for custom blocks
- Slower to load than native React blocks
- Stores data in postmeta instead of post content
- Content isn’t included in editor details (word count etc)
- All functionality has to be manually added (I.e. background/text colours)
- Colour pickers use a different UI to core blocks leading to inconsistencies in the editing experience
Saying bye to Classic Editor
Since its release 4 years ago, Block Editor has made content production a more visual and improved experience. A mixture of core blocks and custom built ACF blocks create a flexible editor whilst allowing for a rapid development cycle. Using the theme.json config file enables us to lock down blocks to retain a consistent design whilst still being customisable and flexible.
Classic Editor will eventually be unsupported by WordPress’s core developers and won’t receive security or maintenance updates. By continuing to develop using Classic Editor, we believe we’d be doing our clients a disservice by limiting the longevity of their website.
It’s not clear when Classic Editor will be fully retired from updates, but as an agency we’d rather focus on the future of WordPress and keeping our skills up to date with the new technologies associated with it.
If you’re a fully seasoned WordPress Block Editor developer looking for a new role with a future-focused agency, take a look at our current vacancies.
And if you’re an enthusiastic developer looking to make the move from Classic Editor themes to Block Editor, then do get in touch – we’d love to help support you on that journey.