There’s been a lot of talk in the WordPress world about whether or not theme developers should build plugin-like functionality into WordPress themes. After my presentation at WordCamp SLC 2012, it was actually something I was asked about. Seeing how it was a topic of discussion on wpmail.me via ManageWP, I thought I’d throw my 2 cents into the mix and why I feel strongly about this issue.
The Setup
The basic premise for theme developers is this: you’re building a theme for a specific market — say an ecommerce theme or a theme for musicians — wouldn’t it be easier to bundle functionality into the theme — say the actual shop for the ecommerce theme or a discography for musicians — that way the user doesn’t need to go looking for those features as plugins. There may be a secondary motivation, too, which is that you could charge more for your theme if you are bundling functionality into it as opposed to just releasing it without that functionality.
The Problem
The issue with this setup (though it may not be a “problem” per se for theme developers, depending on where they stand on users switching to a different theme later), is that it locks in users to your theme if they want to use this functionality you’ve bundled. And what if they don’t want to use it at all — maybe they want to use a different plugin or maybe they’re already using a different plugin? You’re giving people additional options and features that are basically just taking up space in their dashboard. Add to this badly-coded themes that are using jQuery incorrectly or causing other plugin conflicts and — at the very least — you’ve got some support issues you’ll need to deal with.
Case Study: Slightermusic.com
Here’s an example:
I helped my friend, Colin C., launch his new WordPress-powered website for his SLIGHTER project. Previously, he was using standard HTML templates built in iWeb — this would give him the opportunity to do a real blog/news page, manage content easier without having to dive into code, and have the potential to sell and promote his albums easier from his website. I have a fairly busy schedule balancing Museum Themes development, client work, and development and support for Event Espresso, and building a new theme completely from scratch (or even significantly modifying an existing theme to match the sketches he drew and scanned) would take more time than I had, especially since it would be largely pro bono work. Colin doesn’t know enough about the WordPress theme community or environment and has a busy schedule mastering music for clients as well as working on his own projects, so searching through lots of theme shops and marketplaces was uncharted and unfamiliar territory for him. It was perfect timing when I found this post on WordPress themes for musicians. Colin took a look at the list, and picked MediaScene by Devil Can’t Burn, a premium theme on Themeforest. He actually used the word “perfect” to describe it.
The problems set in when he started trying to set up the site to look like it does in the demo. Anyone familiar with this experience will be nodding their heads — it’s one thing to see a theme demo and say “yes! that’s it! that’s perfect!” and — a lot of times, especially with badly-coded themes — a completely different thing to actually set your site up to look that way yourself. To give the author his due credit, he includes a full, 11-page help package formatted in HTML files that go over all the features of the theme. However, even using the help files, it took trial and error to figure out the proper way to, for example, set up the slider, and even I couldn’t figure out how to get blog posts to show up on the home page until I looked at the code. It turns out, that none of his theme options have default settings, but many of them are actually required to have a setting in order to work properly (in English: it doesn’t work out of the box, but it doesn’t tell you it’s not working, doesn’t tell you why it’s not working, and doesn’t tell you what you need to do to make it work).
I won’t talk about the theme options of MediaScene in this post. My approach is to keep theme options as minimal as possible and utilize core WordPress functionality and the availability of plugins when available. Now that Jetpack comes with an awesome Custom CSS editor, I’ve actually been considering removing my custom CSS box in Museum Core (don’t worry, guys, it’s not going anywhere — and won’t go anywhere if you’re currently using it). Devil Can’t Burn has a different approach, building things like background image and color, header logo/image, default email address (for the built-in contact form — full disclosure: this wasn’t working for us, we’re using the contact form that’s built into Jetpack) and various other things that could be done with plugins into the theme options. In fact, pretty much every option in the theme options page could be done with a plugin instead. But I’m not talking about theme options…
The theme also comes with built-in custom post types for the slider images, a portfolio (still not sure what this does), and albums. But I built a plugin — or series of plugins — to handle artists, albums and album reviews that I’m using on Plague Music. With my plugin version, each post type (artists, albums and reviews) is added via a separate plugin, but they use common features and hook into each other. For example, Genre is a custom taxonomy that is used in both Album Releases and Album Reviews, so new genres that are added will be available in both types of posts. An artist can create their page and add their albums, and then their albums are listed on their profile page underneath their bio. Any one of these plugins can be used independently, as well, so you aren’t losing anything if you disable one or more.
So what happens if, instead of using MediaScene’s built-in post type for albums, Colin wanted to use my plugin instead? He ends up with wasted real-estate because there’s no way to get rid of those 3 post types without writing code or hacking the theme. With the plugin version, if someone decided they didn’t want to use it anymore, the could just deactivate and delete the plugin, not so with themes that add those types of features to the core code.
This is a classic example of themes adding functionality that should be handled by a plugin. MediaScene also comes with a load of shortcodes, including Vimeo and YouTube embeds (which you need to use — despite WordPress core’s built-in auto-embedding capabilities — because of how he’s loading jQuery), but the help file just gives you the shortcode and the HTML output, which is gobbledegook to users who don’t know HTML code. Justin Tadlock has made the point many times about building these types of things into plugins instead, or even building your functions.php into a plugin so those options or features can follow you if you deactivate the theme. I tend to agree with him that these things should be built into a separate plugin — possibly one that’s bundled with the theme — though I could be swayed with the slider if it was handled correctly because that ties directly into the theme itself (if you’re switching themes, and the theme is built around a specific slider, you might not want that slider on another theme that has a different layout — that said, any images that were in your previous slider would be lost completely once you switched to a different theme, requiring you to reactivate the old theme, dig through your Media Library or hack your database to get those images out). Even the WordPress Codex has something to say about using the functions.php vs. building that functionality into a plugin instead. And despite popular believe, it’s no “faster” or more “efficient” to build it into a theme than a plugin as this post on WPTuts points out.
Custom functionality for client sites
If you are building a theme for a specific client, all bets are off. As a freelance developer or a WordPress development studio, you want to lock in your clients and your clients are probably using WordPress either because it’s simple or because you convinced them it was. Clients are probably going to go directly to you, anyway, for new features or functionality, so whether you do that in a custom plugin, a third-party plugin, or build it into your theme doesn’t make a huge amount of difference. To make things easiest for clients, some functionality — say, customizing, white labeling, or otherwise branding the look and feel of the WordPress dashboard — could be bundled into the theme you develop for that client. Similarly, you could create custom widgets just for that client for, say, a MailChimp signup form. Building functionality into the theme in this case also eliminates the possibility of the client deactivating a plugin by mistake and then coming to you when things aren’t working as a result. I’d still be wary of overdoing this, though. Abstracting functionality to individual plugins makes things easier to debug if there are problems with a particular feature you built, or if the client decides they want to do things a different way. (I once built a site on a WordPress ecommerce theme that I then had to rewrite to be a standalone theme when they decided they didn’t want to use the ecommerce part.)
The conclusion (or: “read this if you don’t want to read all that stuff up there ↑”)
If you are a theme developer and you are building functionality into a theme that you are selling on a marketplace, your own theme shop, or offering for free, stop right now. Make it a plugin. If you are using a theme that is building in functionality that you are using, find a plugin that does the same thing, because if you ever decide to switch themes, you’ll be SOL. If you are a freelancer or contractor building functionality for a specific client, the scales tip slightly more in the favor of possibly adding that to your theme, but understand that doing so may cause support headaches later on.
Leave a Reply