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.