Should themes include custom Gutenberg block types?

The question has been raised and answered before. Yet it does come up, and will continue to come up again and again over time. Where should Gutenberg block types live? The correct answer, the simple answer is in plugins. Yes, on some level this is counter-intuitive if you think of blocks as being UX elements. Surely UX elements would live in themes? Yet the block-based Gutenberg system isn’t just about the theme layer and the UX. Block “types” are in some sense more about structure and even data storage and potential dynamic handling (dynamic blocks). What lives in the theme, according the concept of abstraction, is the styling of blocks. This includes custom CSS in a theme stylesheet. It includes presets that will in the age of FSE (Full Site Editing) come primarily from theme.json and then be overridden by edits in Site Editor.

Main Reasons You Should Avoid Shipping Theme Specific Block Types

The rationale for advising against shipping theme-specific block types, or put another way… building block types within a theme layer… is because when a site switches from one theme to another those block types will no longer be available. Now if it’s just a content block used in a few places, replacing or removing that content might be fairly easy. But what if the custom block is a page layout, or a custom grid system that wraps content across dozens of page templates? Now you have a site that is completely broken and where most of the content is hidden under Gutenberg validation notices about a missing block and would you like your blocks converted to static HTML that you won’t be able to edit anymore?

A counter-point to make however, is when it comes to commercial site development (company websites) nobody in their right mind wakes up one day, heads in their live WP Admin and switches themes. In reality the vast majority of site theme changes are done during a rebuild process where the new site is completely built, then the old site is tossed in the digital trash heap when the new site is ready to be rolled out. In 18 years of site development, 99% of the time I have seen the “replace/trash” method used, and the only time I’ve seen theme switching is when the decision about which theme is being made early in the process of building. Swapping themes is more of a theoretical exercise than real thing anybody actually does on production sites.

Counter Culture Won’t Die Today or Tomorrow in the WP Ecosystem

It could be argued that breaking the rules is how some of the best innovations happen in WordPress. Take for instance how we ended up at the doorstep of Full Site Editing (FSE). Part of the story was Elementor taking the page building game to a whole new level. They invented a system that acts as a prototype for block editors, perhaps inspired by SAAS block editing that was appearing in software like at the time. By doing something that went against the grain of how WordPress was supposed to be used, almost entirely circumventing the normal editing process, setting up a completely alien template format, storing widgets as JSON snippets, in doing all these things Elementor created a sidetrack that millions of site owners readily accepted and even celebrated. This forced WP to rethink editing. This has now led to the integration of React, paving the way to modernization of WP’s approach to scripting. And now here we are, again laying down rules or at least making assertions about how things should be done… expect it to go the way it always has. Some will follow guidelines, others will not. Some will break the rules at their peril, others will do so in a way that fosters an entirely new and better way of doing things.

Specifically, don’t be surprised if FSE themes often do ship custom theme-specific blocks. Theme makers after all will be under pressure like never before to prove why their premium theme has value. We can’t predict easily what the market will be like, maybe premium FSE themes will be widely purchased. Or maybe the theme market will shrink because the flexibility of block editing and the tools provided by Site Editor make it so easy to share styles, import custom block types and build a site without heavy reliance on a base theme. It could be argued that all you really need in the FSE age is a base theme that provides a few basic CSS styles for common blocks, and everything else can be created or sourced separately.

Theme makers therefore may be tempted certainly to bundle collections of blocks, and to use their fully styled blocks as selling points.

Reasons Themes Might Resort to Shipping Custom Block Types

Aside from the commercial theme makers goal of selling themes and remaining relevant in an FSE environment, there are also some practical considerations as to why themes might need to bundle custom blocks.

In a recent experiment with copying the styles of a popular classic theme named Uppercase, which features a sticky header/sidebar that sites on the left in desktop view we encountered the following frustrations in making a working FSE version of the layout:

  1. Using Columns Block didn’t work because the columns are setup using flex and the properties didn’t seem to work well for us making 1 of the columns sticky. And even if we did adapt it through a lot of custom CSS, it probably was still going to render poorly in the Gutenberg editor. Not to say it’s impossible, as almost anything is possible with enough CSS, but it definitely felt like swimming straight up a cliff. Not advisable.
  2. Second effort was to resort to wrapping our FSE template block content in some custom HTML tags. This experiment did not last long, after realizing any HTML content not wrapped in block comments triggers errors in the Gutenberg editor. We had hoped layout wrapping tags would be ignored? Apparently not.
  3. Third effort was to use the Custom HTML block. After all we were writing custom HTML, so using the Custom HTML block made sense. This experiment nearly cost me a laptop and a window. What do you mean the block is invalid? Turns out Custom HTML blocks are validated to ensure any open tags are closed within the same block. So no, you cannot open a div at the top of an FSE template and then close that div later in order to wrap your blocks.

In summary, as of WordPress version 5.8 and the current Gutenberg plugin at the time, during this phase of “partial FSE support” there is no way (that this author is aware of) to wrap blocks in “arbitrary HTML”. It could very well be the case that this will change before FSE hits the mainstream. Perhaps Custom HTML block will be given an override option like “skip validation”, or maybe a syntax will become available that we can write HTML into templates and wrap them in a “skip validation” comment. The idea being that the editor would then (gracefully?) skip validating, but might (or might not) try to render the non-block HTML. Otherwise layouts that require HTML output that isn’t possible from any core block will result in theme makers choosing between a simplified version of their design, or abandoning the principle of not shipping custom block types from the theme layer.

What will be the penalty for theme makers that build custom blocks?

Theme makers that ship custom blocks may find themselves unable to give their work away for free and will instead have to sell their work and collect buckets of money. #sadge. In seriousness though, it’s not clear what the final guidelines will be but it is likely themes that create block types will be barred from the official themes directory. And that’s a fairly significant deterrent to themes that had a freemium approach to getting their name out there. It’s likely to lead to theme makers being both theme builders and plugin builders. Providing first an FSE enabled theme, but then also having a requirement to install the corresponding plugin. The idea being the theme is still functional without the plugin, but needs some custom blocks from the plugin to reach it’s full potential.

Similar Posts