Spurred on by this strongly worded, and spot-on, post I saw from Leland at Theme Labs about why a theme should never include its own shortcodes, I’ve finally written my thoughts about what WordPress themes are doing wrong.
The Problem with the WordPress Ecosystem
One of the greatest things about using WordPress is that there are so many options to solve your problem. From the crazy-simple to crazy-complex, you can find a theme at almost any price point and visual style. Plugins as well: simple or complex, expensive or free, anything you want. This is largely a great thing.
The problem is, especially in the premium marketplace, non-technical people are shopping for some pretty complex things with little or no way to evaluate the wisdom of their decision. A shopper may think “I know SEO is important and I need a WordPress theme.” “Hey look! This theme says it has SEO. And it has boxes for me to enter my data.”
And for as long as that user continues to use that exact theme and likes the way it looks, they’ve solved their problem. But when they decide they no longer want to use that theme to show their content, they’ve got a real problem on their hands. All those custom page titles and meta descriptions and whatever else they put into their (now old) theme’s SEO features will seem to disappear. Because of that, they’re either left to do a heap of complex technical work, hire an expert to save years of SEO data, or remake all of it from scratch. It’s a frustrating problem that doesn’t need to occur.
The Cause of Theme Overreach
Broadly, the problem that causes SEO data to end up in theme-specific data and data-structures is that the people searching for themes haven’t fully thought through their problem. A person in need of a website sets off to get one. They hear that WordPress is a good way to do that. Then they hear that SEO is important. Then they find out they need a WordPress theme. And so we arrive at our user, through no fault of their own, putting their SEO data inside their theme.
Seller of themes are competing to match each other feature-for-feature because most people in the market for WordPress themes spend their money on a checklist of the features they understand and know they want. They don’t have the expertise or time to understand all the complex implication that will spin off from their theme choice. So if one theme has loads of shortcodes to allow me to easily make sliders, and registers some custom post types I want like “Portfolio” and “Contact Forms” for me, and claims it’ll do SEO, that’s what I’ll buy.
These low-information shoppers aren’t so much the cause of the problem as the victims of it. ThemeForest, laudably, has started to realize this and recently modified its theme submission requirements to begin to limit the overreach of many of the themes they sell. As Leland Fiegal points out about shortcodes they’ve not really gone far enough. But any effort to improve the quality and problem domain of themes is a good thing.
What a WordPress Theme Should Do
When we think about what a theme should do, it’s good to keep in mind a favorite software engineering idea: “Separation of Concern”. It’s a powerful and useful idea that is ignored by too many people in the WordPress ecosystem. The “MVC” pattern, old-hat to most web programmers, is a technique that assures that nothing in you system is doing too much. Your model is your data. You have controllers, which act on that data. And you have a “View” which displays that data.
A good WordPress theme should act as a way to view (and only view) the data that WordPress expects it to display.
A good WordPress theme should act as a view (and only a view) for the data that WordPress expects it to display. It shouldn’t have any effect on the administration area of the site, because a theme generally should not provide any functionality.
Some will argue, reasonably, that themes in WordPress today need to do much more than the default WordPress theme seems to account for. You wouldn’t have a lot of luck selling your dog toys in a blog-type layout. And it’s true: we’re asking WordPress to do many things beyond what the first creators of themes envisioned. But it doesn’t follow that we need themes to both display and provide this functionality. Far better that a theme depend on well-known and established plugins to handle the creation of maintenance of data, and keep their job to the displaying of that data.
If you’re making an ecommerce theme that needs a way to list products, make your theme require WooCommerce, or your favorite ecommerce plugin. Heck, make your own ecommerce plugin. We have tools — admittedly not as well-known, well-supported, or integrated into the core of WordPress as they should be (Brain Krogsgard’s recent post about this problem is highly recommended) — that let a theme declare its dependency on plugins. But don’t put any of the user’s data into your theme unless you’re trying to lock them into you forever. (While that may be a business strategy, it’s not a very good one.)
Four Things a WordPress Theme Should Never Do
Given what we think WordPress themes should do, here’s my list of the things a theme should never do:
- A theme should not register content (post) types. If a theme creates a new element like “Posts” and “Pages”, that means that a user will lose those when they switch themes. An expert can recover that data by declaring that same content type in a plugin, but most regular WordPress users can’t. And why make any users do that? You could have just required a plugin to do it in the first place.
- A theme should create no taxonomies. Similarly, a theme may try to create a new tag- or category-like system, either for posts or pages or a custom post type it registers. (Which it shouldn’t have done anyway, see #1.) Again, while this data isn’t lost eternally — an expert can recover it with some speed — it’s an unnecessary thing for a theme to be doing.
- A theme should not store data, or provide easy interface for some custom type of data store. This is the SEO example I started withL if a theme stores SEO data in some custom data structure that its creator has made up, the second that the theme goes away the data is also lost. And unlike the last two, this is likely to be even more obscure to recover, as even and expert would have to spend some significant time guessing the exact data structure the theme used.
- Finally, and this is Leland’s point: a theme shouldn’t provide shortcodes, or any other specific means of adding unique-to-the-theme elements to post content. There’s no inherent data-loss in this, but it does definitely break my site that where I used to have a pretty button that did something, now visitors see “[pretty_button action=”does thing” label=”Click my pretty button”]”. Again, this is a fixable problem: a custom plugin for those shortcodes will get the job done. But again, there’s no reason that the theme should have done the job in the first place.
How to Build Robustly with WordPress
As a general rule, if you switch to another theme and lose *anything* you care about from the dashboard (outside of the Appearance tab), that theme is doing too much.
As I mentioned above, the key to robust systems is that you decrease as much as possible the irreplaceability of any component. “Modularity” is a fancy word for what we want — each component should be able to be swapped out for any other that does the same job and the system should just keep working. Realistically, this is beyond what’s reasonable given the way WordPress currently works and the way its components build on each other.
But even given the structural limitation of WordPress, keeping your theme’s job to the display of content, and keeping it away from both data storage and the creation of data structures (like post types and taxonomies) is a great first step. As a general rule, if you switch to another theme and lose *anything* you care about from the dashboard (outside of the Appearance tab), that theme is doing too much. Look for a new one, or talk to its creator and point them to this post, ask them to change the way their theme works.
Theme swapability is crucial if you’re hoping to build a maintainable WordPress site that’ll serve you well for years. Educated shoppers should demand it, and WordPress professionals — both makers of commercial themes and one-off efforts for a single user — should always strive to deliver it.
(Checklist photo from xtremexhibits)
Related Posts
Dave this was such a good topic to have at Wordcamp Boston. I thank you for holding the session on Theme Creep and I thank myself for choosing to go!
This is going to save me a lot of aggravation as I will slowly be switching a number of my client sites to a new theme framework.
Thanks again – Anne
Glad you liked it, Anne. Let me know if you ever have any more questions about the issue, I’d love to talk more about it.
Pingback: Getting Started with Google Analytics for your WordPress site | WP Business Tips
Hi David,
I’m curious as to how, when using your approach, you go about making CPTs and custom meta portable from one theme to the next? Lets say i create a bunch of post types and taxonomies with a plugin (which i normally do via Types) and meta boxes with ACF for various post types. I still need to create theme specific files and display code to render this data in the browser (additional sinlge-post-type.php, archive-post-type.php etc). Similarly with the display of custom meta – whether its images, repeater fields, global fields within headers and footers all reside within the existing theme so this still seems beyond the scope of any beginner site owner who activate a new theme and wonders where his all post types went?
Just wondering how you go about this sort of thing and what your thoughts are given that post types and custom meta require reasonably tight coupling to the active theme in order to work properly. I appreciate it’s still more of a separation than post type creation within the theme itself but what is the cleanest approach possible?
Great post btw
Hey Marco,
The very simple version is that for displaying data in a theme — templates like single-post-type.php — I would go ahead and put them in the theme. They’re not about creating the data, they’re not about making the data have the right behavior, they’re about making the data make sense in the context of the WordPress site’s public face. So I’d say they belong in the theme.
Your broader point about coupling is well founded. There’s inherently a bit of a complexity and coupling between your custom data and your theme if you naively put them right into the specific template files. There’s an extent to which it’s just not sane to sweat that stuff to hard for WordPress. (Perfect complete and clean separation between everything is impossible if they need to work together.) I would say that if you’re going to do a lot of deep transformation of data or custom querying for display, I’d spin that off to a specific plugin that provides WordPress-like template tags like the_bracelet_description() etc. Then you can more easily move that into a new theme and not have to copy over what is essentially “bracelet” logic from theme to theme.
Hope that helps!
Pingback: Dealing with Theme Creep | WPShout.com
Yes! An amazing article! Thank you David 🙂
Thanks for the suggestions shared in your blog. Yet another thing I would like to talk about is that weight loss is not about going on a fad diet and trying to lose as much weight as you can in a few days. The most effective way to shed pounds is by acquiring it slowly and obeying some basic suggestions which can make it easier to make the most from a attempt to shed pounds. You may be aware and already be following some of these tips, nonetheless reinforcing know-how never does any damage.