Theme Lockin

A Proven Method for Frustrating Devs: Theme Lock-in

I’m working on a project that involves creating a custom theme for an existing site. The basic scope is to create a new theme and “apply it” to the new site, meaning get all the existing site content situated and looking good in the new theme.

Sounds pretty straightforward, right?

I mean, just create a handful of templates (front page, archive, single post, single page) and go to town. There’s no content restructuring – it’s just taking the existing posts, pages, etc., and making sure it looks good in the new theme.

But here’s the problem:
The previous developer registered several custom post types and included a bunch of custom fields and meta boxes in the theme.

Why is that a problem? Well, it means that, once that theme is deactivated, those custom post types and meta data are completely inaccessible. Yes, the data is still in the database, but there is no admin interface to get to that data.

In a moment of frustration, I tweeted a PSA to please not register custom post types in a theme, but instead use a custom plugin.

All the old devs of the world sagely nodded their head and retweeted my tweet or responded with the nerd equivalent of AMEN.

But then, another dev bravely asked why it matters (I say bravely because I think it takes courage to admit you don’t know something – especially if you think it’s something you’re “supposed” to know).

So, for Cindy (and anyone else who was wondering but didn’t ask), here’s the breakdown.

Themes vs Plugins

At the most basic level, WordPress themes control what a site looks like and plugins control how a site functions. You might hear this called Form vs Functionality. Justin Tadlock wrote the definitive post on the subject in his article, why custom post types belong in plugins.

To summarize it, the criteria for whether something belongs in a theme or a plugin can most easily be determined by answering this question:

Do I still need ______ if I switch to a different theme?

If the answer is YES, that something belongs in a plugin.

If the answer is NO, put that something in the theme.

How to know if something belongs in a theme or plugin: Will I still need it if I switch themes? Share on X

Example #1

Going back to the issue I’m currently facing with this theme switch….there are three custom post types for the site. Let’s ask the determining question:

Do I still need these three custom post types if I switch to a different theme?

YES. Those custom post types should have gone in a plugin. Apart from this theme being activated, there is nowhere in my WP admin to get access to the custom post types.

In order to fix this and make the custom post types “theme independent,” I have to register those custom post types in a plugin (that will work with the new theme I’m building and any theme in the future).

Example #2

Shortcodes! I’m going to sprinkle a butt-load of shortcodes throughout my content to do various things, like add social sharing buttons or create a cool accordion effect on my FAQs.

Do I still need these shortcodes if I switch to a different theme?

YES. If I take a way the functionality that enables me to use the shortcodes, then I’m left with useless shortcodes in my content. So, instead of those social sharing buttons, I just get something like this on my screen:


By extracting that functionality and putting it in a plugin, I can happily use my shortcodes in any theme.

Example #3

Widget areas. Let’s say I have a widgetized front page on my current theme to help display content in certain areas.

Do I still need these widget areas if I switch to a different theme?

NO. Widget areas are quite custom to a particular theme and probably don’t have meaning or use in a different theme, especially since they are only displayed via a custom template and dependent on specified styles. (I understand there are edge cases here, but for illustrative purposes, well, you get the idea…)

The Solution

For anything that gets a “yes,” you’ll want to put it in a plugin.

If you’re doing custom work for yourself or a client, this is not the sort of plugin that ends up in the WordPress repository – it’s just a plugin for your use (and the use of any developers working on a site after you).

The most common term for this type of plugin is a Core Functionality plugin, or Custom Functionality plugin.

I like to use Bill Erickson‘s Core Functionality plugin (I fork it and make this into a unique plugin per site). That’s just my preference, but you could create your own or even use someone else’s core functionality plugin as a base.

Learning More

If the thought of writing a plugin, even for your own use, makes you want to crap your pants, don’t sweat it. Plugins come in all shapes and sizes and levels of complexity and the type of plugin I’m talking about here is on the more basic end of the spectrum.

Andrea Whitmer wrote a great post on How to Create a Custom Functionality Plugin that’s well worth a read.

If you want to start at the beginning, I recommend Pippin Williamson’s Plugin Development 101 course ($6 for a month of access).

The bottom line? Your future self (and other developers who follow in your footsteps) will thank you for separating out your “form from function.” You’ll keep yourself from getting locked into a theme until the end of time.

Featured image licensed under Creative Commons Attribution. Photo by Heb.

24 thoughts on “A Proven Method for Frustrating Devs: Theme Lock-in”

  1. @Rachel Coming from a blogger point of view I sure don’t want to be locked into ANY theme including those custom built for me. I dumped Themify because it was so hard to just change between their own themes. When I departed them it was a lot of work to get my blog back to normal. I learned my lesson and began using Justin Tadlock’s stargazer theme.

    I appreciate your clarifications Carrie – this article is invaluable for us non-developers as well – thank you for even including examples that further clarify do’s and don’ts.

  2. Since the primary issue my article dealt with was within publicly-distributed themes, I added the note so that I’d have to stop reading comments about irrelevant exceptions to the rule in an agency setting. I’d say 99% of the time, this rule applies to client work. It’s just a slightly different set of issues because clients aren’t changing themes on a whim.

    If it can be put into a plugin it should be. It’ll save you (or some other developer) headaches in the future. Separation of form and function is something we should all strive for, despite the setting.

    With that said, there are certainly instances for specific clients where you need to break the rule. That’s a decision you have to make on a case-by-case basis.

    1. Yes.

      If it can be put into a plugin it should be. It’ll save you (or some other developer) headaches in the future. Separation of form and function is something we should all strive for, despite the setting.

  3. > My question would be, at what point do these practices apply to all themes/plugins public or client private?

    Short answer: they always apply. Always.

    Long answer: everything on your site, be it a theme or a plugin, should be self-contained to its specific purpose. A plugin that does two entirely different and separate things, with nothing in common between them other than they were made by the same person or for the same site, is a bad plugin. A theme that does things not related to the display of the site is a bad theme. Simple, really.

    One plugin or a dozen makes no difference when it is just a matter of the same code in one file or a dozen. Only the amount and quality of code matters. Not how you divide it up. How you divide it up affects how you write it, and how you think about it. That matters a fair amount. You’re less likely to add in needless interdependencies when you enforce a separation of code in your brain.

    1. So you’re anti a core functionality plugin (key word being *core*) if it registers CPTS, registers taxonomies, & defines some metaboxes? Or is that an example of things that are closely-enough related…

      One plugin or a dozen makes no difference when it is just a matter of the same code in one file or a dozen. Only the amount and quality of code matters. Not how you divide it up.

      ^^ Thank you for this. I’ve been meaning to write a post expounding on the topic of “too many plugins is bad.”

  4. Only if those things are unrelated. Like, you wouldn’t want to mix a plugin that adds a taxonomy to help organize your photos and a plugin that adds a CPT for, say, Portfolio posts. Those are unrelated things.

    Keeping only related things grouped together makes it easier to debug because you can disable individual pieces of the site without affecting the rest. That’s the real power of plugins: they have an off switch.

  5. Hi Carrie,

    I disagree with your statement: “Your future self (and other developers who follow in your footsteps) will thank you for separating out your ‘form from function.'”

    I believe your rules apply to themes, and themes, and is in fact a requirement for those services. However, I’m disturbed to widen this as a best practice for ALL themes, and ALL clients.

    Maybe it’s because I come from an agency environment, where we do custom designs, but our philosophy is to avoid plugins whenever possible. They’re too fragile and easily deactivated or deleted. By placing the CPT in a plugin, you’re site’s content is now dependent on that plugin loading. This is worse, in my opinion, than being dependent on the theme.

    Additionally, as a developer, I find it quite easy to copy and past the register_post_type, and register_taxonomy calls.

    I get that it was a pain to switch the custom theme for your client, but it only takes a few minutes to add this code into the new theme or child theme. Right?

    1. Hi Paul,

      They’re too fragile and easily deactivated or deleted.

      There’s nothing inherently more fragile about putting that code in a plugin versus in a theme. If you’re working on a client side and concerned about deactivation/deletion, why not make it a Must Use plugin?

      While maybe the separation of form/function is “more important” for distributed code, I think it applies to custom work as well. The project I cite in the post is an example of why it’s not ideal in custom theme. (It’s not just a CPT in this case, it’s a crap-ton of meta data generated by a third-party tool that’s not a matter of copy/paste, but of rebuilding everything on the back-end related to CPT meta. It’s not rocket science, but it’s added quite a few unplanned for hours/cost to the project.)

      I guess there’s always some case that’ll be an exception to the rule, but as a general rule of thumb, I think it stands.

  6. Pingback: #WordPressWednesday 2015 Volume 4

Leave a Comment

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

Carrie Dils uses Accessibility Checker to monitor our website's accessibility.