WordPress is one of the most well-known and versatile pieces of open-source web software out there. With install numbers as high as 60 million websites, chances are you’ve browsed, and even edited, a site powered by WordPress.
The general ease of use and vibrant developer community are just a few of the driving factors behind WordPress’s popularity. However, the release of WordPress 5.0 contained possibly the most controversial update ever: the Block Editor, a.k.a. Gutenberg.
At its core, WordPress is a blogging platform. It was built with simplicity, for both the editor and developer. The dashboard interface is straightforward and follows established design patterns while the blog post editing process is easy to navigate. The install and customization process are perfect for beginners, while the templating system, data structure and internal APIs are robust enough for developers to bend the system to almost any project’s needs.
At Warschawski, we understand that a website is a big investment. Not only do we deliver websites that look fantastic and drive bottom-line results, but we develop sites that are easy for our clients to update and maintain over the life of the website. To that end, we actively avoid jack-of-all-trades themes and page builder plugins which can paralyze a content editor with too many choices and ultimately break down a design system over time.
Instead, we opt to hand craft custom themes and utilize a curated list of plugins to provide a site built with the project’s content needs and client’s editing experience in mind. Advanced Custom Fields Pro (ACF Pro) is one of the most important plugins in our developer toolbox thanks to its ability to completely customize the admin interface of a given post type based on specific content needs.
As the industry has shifted away from thinking about the web as a series of strictly composed templates to modular system comprised of flexible components, we have been relying heavily on ACF Pro, and the Flexible Content field, in particular, to provide a site that can grow and adapt to our client’s needs over time without the loss of visual cohesion.
One of the first things users noticed after updating to WordPress 5.0 was the Block Editor, a radical departure from the standard WordPress editing experience. Gone is the familiar WYSIWYG editor and in its place, we find a brand new interface that is much more in line with the modern, modular web. In this open-source utopia, editors will no longer need to wrestle with inline styles and shortcode buttons or rely on flaky third-party page builders for design flexibility. Instead, they can easily insert and edit different types of content (known as ‘blocks’) all inside an interface that replicates the front-end user’s experience. Developers can throw off the chains of backward compatibility and build newer, better features more quickly, all without worrying about the underlying implementation. At least that’s the pitch.
While the core WP team has stated their reasons behind the rushed development of the Block Editor, one can’t help but think there are underlying financial motivations. Even though the WordPress software is open-source, its parent company, Automatic, is a for-profit organization with WordPress.com as a cornerstone of its business model. Specific figures are difficult to come by, but anecdotally, it’s not hard to imagine that alternative platforms, such as Medium or SquareSpace, have clawed away some of the WordPress market share by offering easy-to-use tools to editors and developers alike; tools not found in WordPress. It becomes tricky to see Gutenberg as a pure and selfless pursuit of better software, but rather a shot across the bow of the competition.
The Block Editor also feels like an attempt to stay relevant to the growing community of JavaScript developers by embracing new tools and technologies. The level of knowledge required to extend the editing experience is far greater than before, which not only has the potential to alienate junior developers and casual tinkerers, but also increases the already astronomical level of technical debt in WordPress. (Remember when you rushed out to learn Backbone.js after the Media Explorer was introduced? Yeah, me neither.) It’s worth noting that some developers are so resistant to the changes that they have gone the nuclear route and released a Gutenberg-free fork of WordPress. With the Block Editor, WordPress can once again hang with the cool kids, and pepper their documentation with Google Trends friendly names like React, Redux, and Webpack.
After working through all five stages of grief over the loss of the trusty Classic Editor, our team decided not to throw a fit, but rather embrace the change head on. Before diving in, we identified our top two goals for using the block editor that would let us retain the flexibility and ease of use which our designers and clients are accustomed to:
With a set of clearly defined goals, and a fresh cup of coffee, we were ready to fire up our editors and get to work exploring the Block Editor.
During our initial review of Gutenberg, we identified that many of the default core blocks would need to be removed in order to maintain design consistency in our projects. Rather than go the filter route, which requires a set list of block to enabled, we found a workable solution with a JavaScript based blacklist approach. This gave us the ability us to remove unnecessary blocks without needing to update a static list when adding a new block. In the snippet below, simply comment out any blocks that you would like to keep:
When the block editor loads, the active items in the array will be removed from the block inserter. This can be added to a theme’s functions file or bundled up as a custom plugin.
After going down the WordPress prescribed route and building our first block, we quickly realized the amount of redundant boilerplate code required to develop a single block was going to be prohibitive, especially if the underlying APIs ever changed. Luckily, the ACF Pro team was hard at work bringing blocks to the masses. Instead of creating Flexible Content layouts or trying to wrangle a mess of custom React scripts, we can use ACF’s new `register_block` function to define a custom block:
Once a block has been registered you can begin adding ACF custom field groups. These fields are displayed when inserting the new custom block, and the field’s values are available in the template file specified:
Creating custom blocks with ACF represents a dramatic reduction in code and allows us to leverage the full suite of battle tested custom fields found in ACF. The ACF block implementation is quite robust and a near perfect replacement for our favored Flexible Layout based system.
After a few hours working with ACF blocks, we felt we had a solid, workable solution, but found ourselves asking a new question: What if blocks could be registered based on a field group, instead of the other way around? This would allow us to version blocks and reduce the amount of boilerplate required to register and draw a block. Luckily, ACF already provides tools to extend the Field Groups to add custom functionality. After a few late nights, ACF Auto Blocks was born.
Auto Blocks is a custom ACF Pro add-on that provides a way for developers to easily use a field group as a block. Once a field group is configured as an Auto Block, the plugin will handle registering and rendering the block both in the Block Editor and on the front-end. Auto Blocks will look for a block’s template file by converting the specified key into a file name and searching the ‘acf-blocks’ directory in the root of your theme for that file. Let’s say you’ve registered a field group and entered ‘testimonial’ as the block key, the plugin will render the corresponding ‘acf-blocks/testimonial.php’ file. Auto Blocks will also localize two arrays for use in the template, `$block` and `$data`, that contain the block settings and field values, respectively:
With Auto Blocks we’re only starting to scratch the surface of layout solutions made possible by Gutenberg, but the early results are promising and have us excited for the future.