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. Great tutorial Carrie! Thanks for taking the time to post about this. No harm in asking if you A) don’t recall the process, or B) don’t know the answer. I find, at least for myself, that asking questions is the best way to learn. I have been known, in my school days, to be severely persistent question after question. In the end, I always ended up as the “go-to” gal, exactly because I understood well the what not-to-do’s and what to-do’s properly. Where as I find, IMO, most folks are too embarrassed or scared to ask. For the most part, I don’t care what other folks think of me asking a lot of questions, especially if it means getting the answers I need.

    Separately, this is a great, handy tutorial you’ve posted there. I’ll admit, that when I first started dabbling into PHP, I did exactly what you’re not supposed to do, add it in the theme itself. Mostly, for me it had a lot to do with I didn’t understand the best practices, even though I was searching and reading the right answers. One of my drawbacks to learning is that I’m often needing too much of a visual guide and find it hard to follow the WordPress best practices. Maybe, this is the case with most newbies, as it all seems so overwhelming to put into play and understand fully. To date, I’m still learning the best practices and hope to continue improving those skills. I

    t’s developers like you that make the development community a nicer place to be a part of. It’s hard enough trying to follow and learn everything there is to learn web related. And oh boy, is there a lot to be learned… Anyway, thank you for your kind support and post. I’m sure many, including myself will find this tutorial useful along the way. Have a super fantastic week! 🙂

    1. Hey Cindy,
      Thanks for the comment (and the original question!). You don’t know what you don’t know… I’m pretty sure I violate some best practice or another every day, but to your point, we’re all learning/improving as we go. 🙂

  2. Hey, this is great. I’m compiling a list of “best practices” for WordPress “Builders” and will add this post about separating content from themes. My list is a brain dump for people like me who learned and are learning along the way how to create sites for others as @MattMedeiros discusses (so glad he commented – I need to put him on the list, too!).

    I created this for my local WP community and students, but I’d love to share and get feedback, input, links, etc. It was like my brain going splat on a page.

  3. Great post Carrie. I’ve been scratching my head about this for a while. Some themes have them, some don’t. Your examples illustrate the proper way to approach this. I like your core functionality plugin solution.

  4. Thanks for being brave enough to tell us what you wish you had done differently. I was inspired to use Custom Post Types right here on your blog (WP-Types +Gravity Forms post). So cool. I have to admit that I became a hammer and, for a while, all the world was a nail. I still LOVE love LOVE custom post types, but most of the time, custom styles for for tags/cats are all I need. *sigh*

  5. Thanks so much for this. As a developer who’s still learning as well, I find that the line between best practices and special cases blur in an agency setting. In the agencies I’ve worked for, projects are especially planned for months and built specifically for that individual client. So I guess the assumption is the client isn’t going to change themes (or we don’t want them to because we want them to come back to us for maintenance = more profit).

    However, I’ve also noticed that not following certain practices end up becoming a headache later on. The client installs a plugin they expect to work but the customization went too far and won’t allow it due to interfering what should “come out of the box” already. Or maybe the client hates the theme we built for them a year or two later and decides it’s time to reboot! Or the client has an existing site with existing custom post types that we’re re-building a theme for. The list goes on.

    I realize Justin’s article specifically mentions that it’s based on publicly distributed themes/plugins. My question would be, at what point do these practices apply to all themes/plugins public or client private? What practices are specifically for an in-agency setting? Or rather, for a situation where the theme is custom to that client only and won’t be distributed.

    This is something I’m trying to clear up for myself every day. Would love to get that perspective or be pointed in the direction of someone who can share that perspective? 🙂

    Thanks again for all the resources! Definitely gonna make use of these.

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.