For many years, I was a hardcore advocate of separating any non-design functionality from themes into their own plugins. I wrote extensively on the issue. Whether it was shortcodes, custom post types, user metadata, and any number of things related to a user’s content/data, I drew a deep line in the sand. This belongs in a plugin.
If you have never heard of the “theme lock-in effect,” that’s OK. For many, it is a non-issue. Places like the WordPress.org theme directory have, for the most part, drew a similar line in the sand.
The goal has always been to avoid trapping a user into perpetual use of a particular theme. It is not an ideal user experience when some crucial data is no longer available when switching designs. And, all users eventually want to change that up from time to time. Getting stuck with [shortcode-soup] tags littered throughout a site is never fun. Neither is losing admin access to dozens, hundreds, or even thousands of pages from a custom post type that suddenly disappears.
The WordPress theme development community has avoided this problem — some more so than others — by bundling crucial content-related features separately in plugins.
Those theme authors who bypassed theme lock-in via plugins have mostly done so in their own silos. For example, instead of integrating with an existing portfolio plugin, they would just create their own. The only themes that support that plugin? Theirs. Ultimately, users were still trapped.
I cannot lay the entire weight of this issue on the shoulders of theme authors. Portfolio plugins are a dime a dozen. Supporting WooCommerce for an eCommerce solution or bbPress for forums are easy choices. But, when there is no clear industry front-runner, an in-house solution is just as good as most others.
However, the block system is already complicating matters. When a theme supports features like font sizes, colors, and gradients, it essentially locks users in. Switch to another with a different configuration, and every font size, color, and gradient the user chose to use is gone.
Imagine inserting a Paragraph block and choosing that sky blue from your theme as the block’s background. Now, imagine doing this a few hundred times only to have it disappear a couple of years down the road when you want to switch designs.
I won’t dive into the technical details of how this works under the hood. It is just the way the system was designed. Some problems could have been mitigated early on, but that ship sailed two and a half years ago with the launch of WordPress 5.0. There are also ways this might be solved in the future with technical workarounds.
Last week, a reader named Nick brought up this issue in regards to block patterns. The theme in question used custom CSS classes to achieve a specific design.
Because Gutenberg lacks all the features mentioned above, the theme uses some custom CSS classes, and these classes are coded in the theme’s style sheet. The problem with this is that now that you have used these patterns, YOU ARE LOCKED IN to this theme. Because the moment you change themes, the new theme will not have these custom classes defined, the patterns will be broken. This is THE SAME reason why shortcodes were outlawed many years ago from inside the themes — and yet when it comes to patterns, this is somehow allowed?
Note: Shortcodes were disallowed in the WordPress theme directory because the actual post content was broken on theme switch. It was unrelated to a broken design.
I already hear what some of you are thinking. This is not the same as “content” lock-in. No, it is not. Not exactly. However, because the block system intertwines content and design, it sort of is. I doubt the average user appreciates the distinction when they end up in scenarios with white text on a white background, as shown in the following screenshots:
Blue background with one theme. 
Blue background gone with second theme.
That is a very real scenario. I see it almost daily as I test out different themes.
And, this is just the beginning. As WordPress’s design system grows and themers can configure more pieces, users will become more locked into their existing theme. Or, they may be locked into one developer’s or one shop’s way of doing things.
I do not necessarily see this as a Bad Thing. We have always had these little silos in the WordPress ecosystem, and they have mostly worked out.
In a sense, little has changed.
Users often stick with the same theme companies for one reason or another. And, those same themers tend to build on top of homegrown libraries or frameworks, reusing the same systems — at least the best ones do. This usually means that users can freely switch between themes made by the same people without losing anything.
The old-school purity test of not mixing content and design is gone.
This is a chance for solo developers and shops to strengthen their brand. If this is the system that WordPress is providing, build strong products on top of it. Build naming schemes that allow users to switch between your themes. Create loyal customers who will want to stick with you for years.
If users are essentially locked into one shop’s theme products, that sounds like a lucrative opportunity to build solutions and healthy user communities around individual brands.
I also envision a future where users will need to switch themes far less often. After the site editor and global styles features become available, users will have more direct control over their design. Once they have settled on a solid theme, they may never need to change it as long as it stays relatively up to date.
Thanks for bringing a topic that keeps me awake at nights Justin. Because of the Gutenberg’s limitations, 2 days ago I found another little trick Pattern developers are using to get around those limitations. This is more acceptable but unseasoned web designers are going to be perplexed if nobody explains to them what’s going on:
This time, the example I will be bringing it’s not from a theme but directly from the soon to be available – core patterns directory – Example pattern: https://wordpress.org/patterns/pattern/illustration-of-bird-with-callout/ .
Testing environment: WP 5.8 beta 2, Gut. 10.8.2
So this is the issue: The pattern comes with a button, if you want to add a second button, one would naturally press the inserter button and create a new button. The problem is that new buttons you create in this pattern will not look the same as the one that comes with this particular pattern. All new buttons will be pill shaped, as the pattern has a rectangular shape. It took me about 15 seconds to realize what is going on, and refusing to look like an idiot anymore, I checked the button’s html code. Surely enough, they had hard coded the CSS code on how the button should look like.
At this point I had 2 choices:
Create a new button, switch to html mode, and add all the necessary CSS code for all the buttons to match, or the easiest method:
Duplicate the button that came with the pattern, and then visually edit the text and link of this second button.
If one does not realize what’s going on, or does not know CSS, will have a hard time doing anything remotely useful things with these patterns, except simple text/images, etc… substitutions.
Finally you mentioned about the old-school purity of not mixing content and design is gone. Well, with it what’s gone are parametric (advanced) searches, and front end editing. I can create a a Real Estate block that will hold all the information regarding properties, but there is no way to ask visitors to submit their properties from the front end, and even though I can search for a house in Los Angeles, OR a house with 4 bedrooms, OR one that costs exactly $1,000,000 (no ability for numeric comparisons here), but there is NO WAY I can ask the site to find me a house in Los Angeles, WHICH has 4 bedrooms, AND costs between $1m – $1.3 million.
For these 2 things (advanced searching & front end editing), you not only need to separate content from design, but your content must be structured, like using custom fields, so you can separate the text from numeric fields, and conduct these complex searches. Some things are simply not possible with Gutenberg, sometimes you have to do things “Old-School”.
I think I just gave you a new post idea for next week… thanks for everything Justin.