WordPress Theme Lock-In, Silos, and the Block System

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:

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.


21 responses to “WordPress Theme Lock-In, Silos, and the Block System”

  1. 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.

    • “Surely enough, they had hard coded the CSS code on how the button should look like.”

      The CSS has not been hard coded, rather it is in the format that the block system recognizes and can interact with. With this you are able to change the background color, text color, and border radius with the block tools in the right-sidebar.

      I was able to add a new button right next to the current button, and style it exactly the same with minimal effort.
      One small issue is that despite the initial state of the border-radius option showing as zero, Gutenberg gives buttons a default radius of 9999px!
      To change this to zero, I had to change the radius up from 0 to 1, then back to 0 for it to take effect. Not ideal in real world usage.

    • You wouldn’t use patterns to build a searchable real estate site or one with visitor submissions. A pattern would be ideal for or a single property site where the site exists only to market that particular property.

      For a fully interactive real estate site, a dedicated plugin would be used.
      The way the block editor then comes into it’s own, would be that the templates that display the property details would be block based, allowing you to edit the layout, design etc.
      In this template you may have a price block, a number of bedrooms block, a gallery block etc. You would then be able to move these blocks around, position them where you want, style them how you want within the property template.
      The properties would be fully searchable as the info for each property is not hard coded on the page, it exists in the database with the front-end display determined by how you have edited the property template.

    • Awesome comment Nick.
      Regarding the parametric search, I think we might see the comeback of {{ mustache }} tags and some form of metaboxes.

      Regarding the white text over white background and similar issues Justin, maybe the directory should enforce the use of default classes along with those custom ones used by the theme developers.

      • Regarding the white text over white background and similar issues Justin, maybe the directory should enforce the use of default classes along with those custom ones used by the theme developers.

        The problem with that is that the default slugs do not follow a reusable naming convention. For colors, they are things like cyan-bluish-gray, luminous-vivid-orange, vivid-green-cyan, and so on. Except for white and black, which are pretty universal names, it is a bit of a mess.

        • Very creative names, lol.

          That, currently, is a developer problem and not a user one.

          Unfortunately, it could also become a user problem if, at some point in the future, it is decided to set up naming conventions and since the current stance on things (since WP 5.0) is no longer backwards compatibility, we could re-encounter this problem of broken design/display.

    • As Andrew said, the Button CSS is not hardcoded. It’s created using the standard block options. But, that does bring up an interesting UX issue that I had not thought about. If users expect the same-styled button, they cannot get it by clicking the “+” icon to add another.

      They must either recreate it themselves or duplicate the block (assuming the user knew how to duplicate). This is also the same issue without choosing custom color and border options. Simply selecting a block style like Fill vs. Outline would result in the same behavior.

      For the Real Estate block, you could technically save content as metadata. However, I would create a CPT instead. Then, create a custom Real Estate Search block for advanced searching of metadata, terms, etc. I can’t think of any good reason to try to encapsulate all of that into a single block outside of a site that showcases more than a handful of properties at a time.

      • About the CSS, I could have chosen a better word I guess, I should have said hand coded and not hard coded.

        As far as the silly example that I brought up – the Real Estate site, using CPT or not or using a plugin or theme to code it, has NO bearing in what we are talking about here. The issue on hand was old-school vs new-school. And unless I’m totally wrong, Justin, by you suggesting to use metadata (which I had already suggested – because it’s the only way), you are re-enforcing my argument. By using metadata, you are separating content from design. Not only you are separating the two, but you are getting the data and structuring it by field types (at least that’s what ACF and Tooset do). And that is old-school, which makes it very much alive, and still necessary in many instances.

        Nothing is perfect though… With metadata you get really bloated databases that Gutenberg avoids by combining the content with the design, but once again, that could be another blog post idea to explore.

        Bottom line, using blocks or metadata will depend on one’s priorities and necessities, and both approaches have their advantages and disadvantages. I think it’s up the Tavern’s of the world to bring up these controversial subjects to raise awareness, resulting in better core code quality and make things better. There is a reason while WP is 41% of the Internet, we are never going to see the next Facebook, or Twitter, and any app. type site, like a globally popular Classified, or Auction site, made with WordPress. Before jumping on me again, I’m talking about sites with millions of users, and billions of records in the database(s). Of course, it is possible to go the WP route, but it will be extremely expensive, in terms of hosting and database load balancing – you better use something else.

        • Nick, you are right that using a plugin has no bearing on what you are talking about. When I mentioned using a plugin it was my clumsy way of trying to explain what was going around in my head.

          When you say that gutenberg combines the content with the design, I don’t see that as entirely true, it only partly describes Gutenberg blocks.

          It’s true there are blocks that are content and design combined such as;

          There are also blocks that are dynamic combined with design such as;
          Site Logo
          Site Title
          Post Date
          Post Author
          etc.. way too many to mention here.

          What I’m trying to say is that when writing a post, you wouldn’t manually add the name of the post author, or the post date using a paragraph block for example.
          These dynamic blocks exist so that they can be used in the template that is powering the posts. These blocks can be designed in any way you want; change the color, background, size, spacing etc. but you dont’t manually write the content of the block each time you use it in a post. This is where the templates come in, allowing you to move these dynamic blocks around, add or remove these blocks, and edit the design of these blocks just how you like.
          A separate issue, but kind of the same is that there needs to be some way of distinguishing dynamic blocks from content blocks in the block inserter, as it is currently not immediately clear which is which. I’m sure there are many discussions in github about this.

          Likewise with the real estate – it’s not a silly example – is a good example of how things initially seem confusing. I didn’t see the point of the block system to begin with, but as I worked with it more there was a point when it suddenly clicked and became clear to me the potential of Gutenberg blocks.

          With the point about the CSS in that particular block pattern, there really is no way to tell whether the CSS is hard coded (or hand coded) by looking at the html code. The resulting code will be identical whether the author used the block tools, or wrote it by hand (assuming they didn’t make a mistake when hand coding it). There may be clues that a pattern could have been hand coded such as ordering the style args differently to the order that the block tools would output, but the order doesn’t matter as it will still work just as if the pattern had been created fully with the block tools.

  2. Thx for the article, interesting issue. I found your anti-locked in arguments more convincing than the pros. Modularity anf customization possibilities should focus on the user perspetive, not the brand. And sometimes theme provides way to much features, I often feel that it would have been simpler to just edit few CSS lined than finding my way in customize menu and sub menus.
    We may find advantage in the new paradigm but it doesnt seems than better than the old. Just different, with some advantages, and some cons.

  3. I’m surprised that even nowadays there isn’t a way to port styles over to some kind of universal system within WordPress to avoid this issue. I think it stems from the fact that developers/brands want you locked in (purposefully) to keep using their products.

    I can understand why, however it creates a lot of trouble for site owners to migrate to different themes and plugins over time which does hold back the community in improving their sites. I don’t think there’s an easy answer to this, but hopefully a solution can be thought of.

  4. Very good points, Justin! It’s like we took the old page builder lock-in and just moved it over to the native editor. I guess that’s better, but still something we need to think about.

    As I’ve built more client themes with Gutenberg in mind, I’ve tried to find some ways to work around it. For instance, I went from creating custom ACF Blocks and sticking them into the theme to creating a custom plugin that allows them to survive, no matter what theme is used. Any custom block CSS is also included in the plugin.

    Developers are going to have to consider these things. But it will be interesting to see how Full Site Editing impacts the theme market. Maybe you’re right and people won’t see the need to change themes as often.

  5. As is often the case Justin, the very last paragraph of your article is the one which resonates most with me.

    I see a future where themes will be just a starting point. When the user is able to edit every template/template part, and the global styles too, and also create their own templates that maybe didn’t exist in the theme, at what point does the site become unrecognizable as being “powered by” the base theme?

  6. This has been on my mind a lot, too. You’ve explained it much better, and it’s something that we need to think about as both plugin and theme creators.

    One thing that can really stump end-users is if they don’t know how their site was built, and what will happen if they decide to change something. That tends to freak people out, and they sometimes want to just start over and give up.

    I’m not sure how we overcome that, when some of these issues are pretty nuanced and technical.

  7. I’ve been a WordPress fan since 2015. I have two WP.com blogs. One is for poetry, which is simple with a black background (I love black backgrounds because it adds appeal to certain types of literary works.)

    I have another blog, where I run a weekly prompt. Once weekly prompt posts gain momentum, the blog host has to find ways to maintain and hold their participants. This is where a theme with a few extras wins the blogger’s attention.

    I’ve tried many of the WP.com Premium themes and finally found one that addresses pingbacks and actually lists them all in one area. I love this feature because I can avoid using Mr. Linky to present a wrap-up post to my participants. Yes, I feel locked into this theme and hope it continues to be updated (Opti). I miss some of the themes that were not updated because they were unique by design. Thank you for all you do WordPress.

  8. when they end up in scenarios with white text on a white background

    Which can only happen if colors are hardcoded within content – which reveals a “broken by design” problem of the underlying editor.

    • You don’t have to hardcode colors for this issue. You just need a lack of a standardized class-naming system. It has far less to do with the editor itself than convention.

      Hardcoded colors would have actually prevented this situation because the blue background would’ve still been there. But, using them would create other design problems.

      • Hardcoded class-names are basically the same as hardcoded colors.

        The main problem is that the editor obviously stores information about layout, colors, typography etc. within the content itself.

        That will always lead to confusion if some day another “theme” should be used and tries to show that content or if content should be exported etc.

        All layout, color, typography information should be stored in some post_meta or similar – not in content itself.

        • Classes are not the same as an hardcoded, inline styles. They are similar if you use class names like .has-blue-text-color, but that is a far cry from a class like .has-primary-text-color.

          Storing the same thing as post meta or elsewhere does not address the issue either. Those still need to be printed out somewhere, and you still must tie them to the block itself either through a class or ID.

          Utility classes are always going to have their place, particularly if you are going to pass some level of design control down to the user. But, there are ways of doing them that are more forward-compatible than others.

  9. 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.

    Have the blue background just disappear isn’t ideal in this situation, but neither is keeping it. What happens when someone updates their brand color scheme and that sky blue – from a theme or from the default gutenberg color options – has been added hundreds of times? If the website lasts longer than five years, the user will probably want to update the look at some point.

    This is why mixing design in with content and then saving the settings of every block separately in the database is a mistake. We’re practically back to html font tags. React was not designed for this either, CSS and html were supposed to mix together, but the data layer was supposed to be separate.

    It’s one thing to give users an option to override defaults and take things into their own hands, it’s another to put every user in the position of having to make design choices and then get locked into those amateur choices because it’s too much work to update hundreds of blog posts.

    If I’m missing something here, let me know. I’m still astounded that the system was designed this way.

    • Have the blue background just disappear isn’t ideal in this situation, but neither is keeping it. What happens when someone updates their brand color scheme and that sky blue – from a theme or from the default gutenberg color options – has been added hundreds of times?

      The ideal situation would be that the blue would transform to your new brand color.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.