Justin Tadlock · November 12, 2020 · 23 Comments
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 WordPress.org 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.
Posted in Opinion
