Replacing Metaboxes: Going Gutenberg Chapter 2
Going Gutenberg is an ongoing series about our process of integrating our products with the WordPress block editor. View all chapters in the series here, and be sure to follow us on Facebook or Twitter to never miss an update.
In Chapter I of the Going Gutenberg blog series, we examined how the introduction of the new WordPress editor—codenamed “Gutenberg”—is a rare and exciting opportunity to evolve our plugins. It’s time to take a closer look at how, specifically, The Events Calendar and its add-ons will be impacted by the new editor.
The Event Post Type
The heart of The Events Calendar is the event post type, so getting the new event editing experience right is our initial focus. The event details metabox, for example, is the place where users enter the most essential information about the event: its start date and time, organizers, location, etc.
This metabox currently works when Gutenberg is enabled, and the Gutenberg team has made clear that such metaboxes will continue to work for a long time. In theory, then, we could let Gutenberg take over the title and content fields for the event post type, and just plunk the event details metabox in the bottom of the editor.
This would look something like how WooCommerce’s product post type currently looks when the new editor is enabled, which can be seen below:
WooCommerce’s current solution for rendering their metabox in Gutenberg.
This kind of solution isn’t right for us because we want to take advantage of the new UI and the JavaScript-based blocks system. Keeping the metabox makes more sense for plugins like WooCommerce because they need to handle a lot of post data that does not have a direct visual counterpart on the front end. Events content can take better advantage of the WYSIWYG nature of the block editor. As a user goes through the event creation process, they’re also assembling the layout and appearance of the front end through the block UI.
Our goal is to take advantage of what Gutenberg lets us do: Ditch the old-school metabox altogether. Event details will now be handled in a set of default blocks for the event post type. We’re neck-deep in the design and development of this overhaul, so things are likely to change, but here’s a sneak peek of how our event post type’s edit screen might look when our Gutenberg extension for The Events Calendar is activated:
A sneak peek of how the events post type might look in Gutenberg, a.k.a. the block editor.
Remember, the details of this design are subject to change—but if we successfully overhaul our event editor like this, it wouldn’t just look great; it would make events easier to create and customize.
Where Gutenberg Can Grow
As part of our development and design process, our team has spent a lot of time playing with the new block editor. In doing so, we’ve run into some impediments that we’ll need to strategize around. Hopefully we’ll be able to come up with some clever solutions, and contribute back to the Gutenberg Project wherever we can.
No Required Blocks
Currently, any block you add in the new editor can be removed. This makes sense most of the time, but with events, we have at least one block that should never be deleted: the block that contains the event’s time and date. This block (and the data it contains) must always be present, because it’s essential to the very concept of the event post type.
We hope for a way to make this block non-deletable. There are some “hacky” workarounds we can try using, but they deviate far and wide from best practices, and having a built-in method for making a block non-deletable would be ideal.
No Storage and Reusability of Block Layouts
Let’s say you go to create an event with our new blocks-based event editor. You spend several minutes adding blocks, dragging them into various positions, configuring block settings, and previewing how it all looks on the front-end. You continue to tinker this way until you get it just right, then finally publish your event.
Onto the next one! So you go to create another event, and…none of your previous block configurations are reusable. So you have to recreate that layout from scratch again—not only for this event, but for every subsequent event. For folks with complicated event layouts or those who want to have a consistent event design throughout their calendar, this could be a major pain point.
Project Gutenberg currently has a templates feature, which allows a custom post type like ours to define which blocks appear as default. The project handbook lists reusable page templates as one of the planned additions for a later release. We’re excitedly keeping an eye on things so we can take advantage of this kind of functionality as soon as possible. What we hope for is the ability to save an event template—complete with block configurations and settings—which you can then reuse whenever you create another event.
Backwards-Compatibility Concerns with Block Content
The actual content of blocks is rendered in a unique way on the front-end: It’s essentially saved in HTML comments that are then interpreted and turned into markup on the rendering of the page. As plugin developers, we wonder—and worry—about the implications of this approach in terms of backward compatibility. Say, for example, we want to update what content parameters are generated by our blocks: There are currently some migration methods that update the post_content field on past events to ensure the block content doesn’t break. But for very large sites with lots of content, this sort of migration can be problematic. There’s just not a good solution for updating lots of content yet, and since many of our users have tons of events, this is something we worry about.
Approaching Our First Milestone
While the three limitations above have given us a lot to think and talk about, they haven’t slowed down our development work all that much. And they haven’t sullied our excitement over the blocks editor one bit. For one thing, the new editor still has a long road to completion and launch. Dozens of brilliant people are working hard on it, and in even a couple of weeks from the publish date of this post, the nature of one or more of these limitations could be significantly different.
But more importantly, the more we dig into the blocks editor, the more possibilities we see for the future of WordPress generally and The Events Calendar specifically.
We’re stoked to keep iterating our plugins alongside the changes in WordPress Core, and have already made great progress with our initial blocks-editor extension (which should be launching in a few weeks).
Be sure to subscribe to this blog and/or follow us on Facebook and Twitter so you don’t miss Chapter III of Going Gutenberg, where we’ll finally share Version 1 of the extension that enables The Events Calendar’s block-based editor for events and details the solutions we came up with.
🔔 Please Note: This is a blog series about active development and exploration. Anything we mention here is subject to change, and this blog series should be read as a tentative roadmap for our products—not an official release plan.
Want more Gutenberg news? Sign up for our Block Editor updates.