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.How to know if something belongs in a theme or plugin: Will I still need it if I switch themes? Click To Tweet
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).
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.
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…)
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.
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.