A Proven Method for Frustrating Devs: Theme Lock-in

Carrie Dils

June 17, 2015

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

@cdils Hi! For the noobs, would ya consider creating a tut what not to do and how to do it right. I’m curious what u mean. 🙂

— Cindy J Bryant (@CindyJBryant) June 9, 2015

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.

[bctt tweet=”How to know if something belongs in a theme or plugin: Will I still need it if I switch themes?”]

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:

[social-buttons]

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.

Comments

24 responses to “A Proven Method for Frustrating Devs: Theme Lock-in”

Cindy J Bryant

June 17, 2015

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! 🙂

Reply
1. Carrie Dils
  
  June 17, 2015
  
  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. 🙂
  Cheers,
  Carrie
  
  Reply
Matt

June 17, 2015

…or/also abstract important content layouts & content areas from the design with a plugin like Conductor 😀

Reply
1. Carrie Dils
  
  June 17, 2015
  
  #medeirosing
  
  Reply
askwpgirl

June 17, 2015

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!). http://wpbestpractices.org/best-practices-wordpress-users/

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.

Reply
1. Carrie Dils
  
  June 17, 2015
  
  Great resource! Might be worth breaking it up into multiple posts for easier browsing/digesting?
  
  Reply
jackie D’Elia

June 17, 2015

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.

Reply
1. Carrie Dils
  
  June 17, 2015
  
  Thanks, Jackie. The comments on the Justin Tadlock post are also quite enlightening in the examples given. It’s worth a browse.
  
  Reply
Ginger Coolidge

June 17, 2015

Yep, this post is definitely getting Evernote-ed 🙂

Reply
Sheryl C

June 17, 2015

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*

Reply
1. Carrie Dils
  
  June 18, 2015
  
  Custom post types are the bomb shizzle!
  
  Reply
Steve Horn

June 18, 2015

Thanks for another great post, Carrie. I’m ready to break into plugins now. Quesadillas and lagers are sure to come your way!!

Reply
Rachel

June 18, 2015

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.

Reply
Marcus Tibesar

June 18, 2015

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

Reply
1. Carrie Dils
  
  June 22, 2015
  
  Thanks, Marcus.
  
  Reply
Justin Tadlock

June 19, 2015

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.

Reply
1. Carrie Dils
  
  June 22, 2015
  
  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.
  
  Reply
Otto

June 21, 2015

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

Reply
1. Carrie Dils
  
  June 22, 2015
  
  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.”
  
  Reply
Samuel “Otto” Wood

June 22, 2015

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.

Reply
Paul Davidson

June 23, 2015

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 wordpress.com themes, and wordpress.org 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?

Reply
1. Carrie Dils
  
  June 24, 2015
  
  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.
  
  Reply
Rachel

June 24, 2015

@Justin Tadlock Ah, understood then. Thanks for clarifying. I’ll keep that in mind now. 🙂

Reply
#WordPressWednesday 2015 Volume 4

June 24, 2015

[…] Carrie Dils talks about something that can be frustrating when switching from one developer to another – A Proven Method for Frustrating Devs: Theme Lock-in. […]

Reply