Do Not Build Theme-Specific Block Plugins for WordPress, Please

A few days ago, I came across a small library of blocks. As always, I was interested in seeing what this new plugin brought to the table. Would it surprise me with a block that has not been done before? Would it present a new take on some old ideas? Or, would it be the same old set of blocks that every other block bundle has? Regardless of what it offered, I was excited to try it all the same.
As I clicked on the description to find out more, I was immediately let down. The plugin specifically stated that it was built for only one theme. I could not use it with my preferred theme.
This was not the first time I had run across this issue. Other theme authors have built their own block bundles in the past. The plugin was not bringing anything particularly new to the WordPress community. It had less than a handful of blocks that had already been done before in numerous other plugins.
The problem was that this felt all too familiar.
Over the years, the WordPress community has created a set of unwritten rules regarding what belongs in a theme vs. what belongs in a plugin. Custom post types, taxonomies, and shortcodes are plugin territory. To an extent, widgets should also be exclusive to plugins. However, because of the way they are handled under the hood, there was always an argument that it was OK for themes to register them.
This theme vs. plugin argument has been ongoing for at least a decade. Because of how themes work, such arguments have been a losing battle. Except in a few edge cases, themes could do everything that a plugin could do. However, there was always supposed to be a clear-cut distinction between the two. Themes were meant to handle the front-end design of a website. Plugins were for everything else.
Today, the WordPress project and its block system are making progress toward solidifying that distinction.
Because of WordPress’s legacy of having various parts that did not all quite fit together in the past, it has created a culture of developers building in-house solutions. Nearly every large theme development company has its own plugins for overcoming the platform’s shortcomings. Most of the blame for this lies with the WordPress project. However, the project’s move to blocks is creating a standardized system that handles everything from a paragraph to the overall site container. With standardization across the board, there will be less and less need for these custom solutions from every theme company.
The block system set a clear line in the sand. It removed the need for shortcodes — good riddance — and will soon phase out widgets. Blocks should be putting those old questions to bed.
For clarity, there is little difference between bundling blocks with a theme and building a separate plugin that only works with a specific theme. The end result is the same. Such a plugin would lock a user into sticking with that theme if they relied on the plugin at all. Few people maintain the same front-end design forever.
The goal is to allow users to switch themes at will while having access to their content and blocks.
These theme-specific block plugins are thinking about blocks in the wrong way. When a user installs a block plugin, the expectation is that they can use those blocks regardless of their theme.
The solution for themes is to use block patterns or styles. Suppose that you wanted to create a slider or carousel as a theme author. There are multiple solutions for this. The first and easiest is to simply recommend a plugin to users or build a plugin of your own that works with any theme. You could also easily add a slider style for the Gallery block. When the user selects it, it transforms the gallery into a slider.
Or, suppose your theme needed to offer a big hero section with a call-to-action button. There is no need for a custom block in this situation. Theme authors can almost exclusively do this by building a custom pattern with existing blocks.
The solution is not to bundle the block in the theme or create a plugin that only works with that one theme.
The beauty of the block system is that most of the pieces are already in place, and they can be rearranged, grouped, and styled in unlimited ways.
Today, there are hundreds of theme-specific plugins in existence. Part of that is because themers were working around the theme review guidelines. Part of that is because some developers did not think creatively enough about solutions. But, the biggest part of it has been because WordPress has not standardized how to build things across the entire platform. Much of that has changed and will continue to change as full-site editing crosses the horizon in 2021. There will be clear paths for themes and plugins.
However, if theme companies continue building theme-specific blocks, we are just lugging along the baggage that the block system is meant to leave behind.
So what was the name of the theme you were trying to use?
Great article Justin, and I couldn’t agree more for blocks published for others to use.
I would be curious however, to hear your thoughts on how you think this should work when it comes to custom built solutions. One of the biggest complains I have with Gutenberg when it comes to more complex layouts is separating the page structure from content.
For simple pages, I make use of most of the core blocks. On more advanced pages however, the homepage being a common one, I find it’s easier to create custom blocks using Advanced Custom Fields for each section/row of the page so the client doesn’t have to worry about the visual/UX side of things.
I normally batch these blocks into the custom theme I’ve built, which I don’t personally like as I know content would be lost should the client ever change a theme. I always try to explain this to the client before starting work so they’re never caught out.
My problem is these blocks are often so specific and design heavy that they would probably look odd if used out of context with a different theme. It’s a problem I struggle to find an answer to every time I build a new block.
I’d love to hear your thoughts on this.
Hi I’m not the author, but want to share my intake with your issue.
Most of the time you only need custom blocks for Pages or whatever your custom post type is. So limit the block to only be selectable in Pages.
Broken pages when changing theme is a normal and expected thing even before Gutenberg, so you don’t have to worry about that.
But blog posts should only use built-in blocks so they stay intact.
Totally agree with the article, Justin.
Building a theme-specific blog plugin (or any kind of theme-specific plugin) will flood the with them. They make the theme-plugin separation useless, and thus the presentation-functionality separation useless.
Instead of building such block plugins, theme authors should try to leverage the available blocks in Gutenberg to do useful things, such as adding block styles.
I have an useful case of using Gutenberg blocks: we make a small plugin called eRocket that use Gutenberg social blocks to create a contact widget (which shows social profile links) and social sharing buttons. I think it’s better to stand on the shoulder of Gutenberg to build things instead of adding more similar things to it.
This is I believe what happens when theme authors have been in a quandary as to what the future holds for them relative to Gutenberg enabling FSE. For them, the future is not clear. So they would rather create theme specific blocks to lock their customers in.
Will they create an FSE version of their current themes? Or will they just migrate their existing themes to FSE?
Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.
Enter your email address to subscribe to this blog and receive notifications of new posts by email.

WordPress Tavern is a website about all things WordPress. We cover news and events, write plugin and theme reviews, and talk about key issues within the WordPress ecosystem…read more →
Proudly powered by WordPress.


Leave a Reply

Your email address will not be published. Required fields are marked *