Theoretically speaking, themes dictate a WordPress website’s design and presentation, and plugins dictate its functionality. This is certainly the intent as outlined over at WordPress.org:
…the WordPress Theme system is a way to “skin” your weblog, [and] plugins are tools to extend [its] functionality.
But this theory often does not translate into reality — themes often include plugin-style functionality, and to a lesser extent, plugins incorporate design factors.
That is to be expected. Given WordPress’ open source status, there are bound to be lines crossed by adventurous developers. And whilst we should encourage innovation within the WordPress community, one must always return to how the end user benefits.
With that thought in mind, I decided to approach some seriously talented WordPress theme and plugin developers, to find out what their position is on the question as to whether or not themes should include plugin-style functionality. Here’s what they had to say.
How Did We Get Here?
Given that a clear delineation between design and functionality is intended (in a perfect world), one might question why we have arrived at the current scenario, where the lines are so easily crossed. Matt Cohen, Product Manager for WooThemes, had the following to say on the subject:
When stepping into WordPress development for the first time, the majority of users tend to lean towards theming, as there is a direct visual result of one’s efforts and, frankly, it’s a more familiar concept to many. This immediately sets a boundary wall, where the developers feels most comfortable working within the theme itself. As WordPress technically allows for this, they carry on, either unaware of the alternative, or apprehensive to take the plunge.
Whilst Matt’s comments make perfect sense (and is no doubt true), it doesn’t account for why well-established theme shops (who employ highly-experienced developers) blur the lines between themes and plugins. However, I didn’t have to look far for clear reasoning from Matt:
From a business perspective, offering a single package containing all the functionality on offer is a tempting concept, as it’s the smoothest setup process for the customer. They install and activate the theme, which presents them with all the functionality listed on the sales page on your website. No extra clicks required. To the end user, who may not be tech or WordPress-savvy, this is an immediate win and, in many cases, the difference between a theme with all the features and activating a selection of plugins, ends up being perceived as “more work” for the customer, to which they may not respond positively.
Matt is not alone in his thought process. Siobhan McKeown, a longtime WordPress writer and web designer, had the following to say:
It’s not about people who build websites, but about people who need websites. If I run a sports club or a doctor’s surgery or a restaurant, would I prefer to faff around with a WordPress theme and source all of the functionality that I need, or would I prefer a theme I can install that comes packaged with everything? Definitely the latter. Which makes for a great opportunity for people who run WordPress businesses, as we’ve seen with happytables and, more recently, WordPress.com weddings. These sorts of all-in-one packages make for a better experience for specific markets.
From the above comments, you can understand why themes often include certain elements of functionality.
However, the same logic applies on both sides of the coin, as highlighted by Rob la Gatta of Modern Tribe:
Our Events plugin needs some views, for example, but of course it wouldn’t make sense for us to distribute a plugin with the functionality and a theme with the views, because we want our plugin to work seamlessly with any theme.
The Benefits of Seperability (and the Risks of Consolidation)
So it seems that there are situations where developers feel that it is beneficial to the end user to package form and functionality into one neat package. That approach seems best suited to specific verticals, where business owners may be looking for a one-stop solution.
That may all be true, but any such packaged theme brings its own challenges and limitations. Brian Gardner, founder of StudioPress, believes that, for the most part, a clear delineation between themes and plugins should still exist. The benefit to him is clear:
Not only does this make it transportable from theme to theme, it also allows for an easy path to upgrade with the WordPress.org repository.
Brian’s point may be brief, but I do not want to underplay its importance. The problem with all-in-one theme solutions is that the inbuilt functionality cannot, as Brian says, be transported from theme to theme. If you want to overhaul your site’s design, you also have to start from scratch in terms of functionality. This view was shared by Rob la Gatta, on both sides of the coin:
If I switch from or disable a theme, I should not loose functionality from my site. Conversely, if I enable a plugin, it shouldn’t bork any visual development done on my site so far.
When I brought this topic to attention of prolific plugin developer Lester Chan, he raised a cogent argument:
I don’t think themes should include plugin-type functionality. For example, my WordPress plugin WP-PageNavi is a simple plugin, I have seen some themes just copy out the functions and paste it into the theme’s functions.php file. It may be convenient for the theme author to bundle it and distribute it, but what if there is a security hole in the plugin that the theme author copied? There is no way for the end user to update that pasted portion of the plugin in the theme.
Generally speaking, design code does not represent a security compromise. Plugin code most certainly can do. If we have unscrupulous theme developers lifting code from plugins and inserting it into themes, can we trust that theme to be secure in the long term?
Of course, one could argue that you shouldn’t use themes from such developers, but some people will be naive to that fact.
Popular Theme Functionality and their Superior Plugin Counterparts
There are popular free plugins available that handle some of the most demanded elements of functionality within WordPress. Obvious examples would be SEO by Yoast and Contact Form 7.
And yet, some themes come packaged with SEO functionality and contact forms. Is this really necessary? Dumitru Brinzan, co-founder of WPZOOM, thinks not:
A theme should not contain (or impose) features that can be easily handled by popular and easy-to-use plug-ins, for example SEO options. Leave that to professionals and experts in the field.
Or contact forms, it is better to provide many alternatives, than to hard-code your own forms into a theme.
Dumitru makes a very good point here. Plugins such as those mentioned above have been developed for years, and are generally recognized as being excellent solutions. So why should a theme developer attempt to build comparable functionality within their theme?
Exceptions
The general consensus amongst theme developers is that it is not possible to give a black and white answer to the question of whether themes should feature plugin-style functionality. Some are clearly advocates of the “app themes” model, where the end user is provided with an all-in-one solution. Others meanwhile believe that there should almost always be a delineation between design and functionality, so that a user can move between themes without risk of breaking their site.
However, all of the developers I interviewed did agree on one point — there are always exceptions to the rule:
Of course there are certain cases when you have to bundle some functionality…features that are hard to achieve or style with third-party plug-ins. — Dumitru Brinzan
There are some instances, very minor ones, where the functionality is so specific to a theme that we feel it’s ok to include that into it. — Brian Gardner
If the functionality in question directly influences the presentation layer of the theme, or the presentation layer relies on the functionality, it should be included [within the theme]. — Matt Cohen
Although developers almost unanimously agree that certain elements of functionality “must” be included within themes, the extent of such functionality is certainly open for debate. For instance, Brian Gardner specifically referenced custom post types as an example of functionality that should reasonably be incorporated into a theme, whilst Timothy Wood, a developer for Modern Tribe, specifically mentioned custom post types built into themes as a bugbear.
If one thing is clear from discussing this matter, it is that there is no clear answer, nor any clear agreement in the design community.
Rule-Breaking Breeds Innovation
However, one thing is for sure — the unique approach to WordPress development taken by many has resulted in many outcomes — both positive and negative. When it comes to encouraging rule-breaking to engender innovation, you cannot have one without the other. Matt Cohen has this to say:
We, the community, have taken various in-roads into advancing functionality offerings within themes and plugins, and have discovered our own methods for doing so. While these may not always be the best or cleanest methods in terms of the “presentation vs logic” split, these in-roads have lead to important advancements within WordPress and the WordPress community, which may not have been possible, had no-one taken any risks or done things “their own way”.
I couldn’t have put it better myself. May the experimentation and innovation continue — even if it does require a little rule-breaking.
Japh
This was a good read on the reasons for separation and the challenges associated with maintaining it, thanks.
I’m surprised Thomas Griffin’s TGM Plugin Activation class wasn’t mentioned.
It’s a very easy to implement solution to bundling plugins, but maintaining separation and the ability for the plugins to be updated.
Japh
Oh, if you can’t tell how the class would work from the GitHub repo linked above, I recorded a brief introduction to its usage on Wptuts+.
Tom Ewer
Thanks for the suggestion and links Japh!
davidkane
The TimThumb debacle – spread across multiple theme vendors – is probably one of the most important reasons for not crossing the line. Way to many themes were dependent on this code, way to many themes designers *still* have not resolved it adequately. It’s still a malware distributors wet dream. Themes dependent on code that makes life easy for the developer (a plugin) bound to the theme in a way, in some instances, that introduced code breaking errors for a function already included in the WordPress core – albeit more work to implement – isn’t adding anything and crosses over into negligence.
Mike Schinkel
If WordPress had dependency management built in and it was promoted as a best practice then the themes could have referenced one canonical source for TimThumb and then users could have been notified by the core WordPress code of a critical update and none of the theme vendors would have had to take any action for the problem to be solved by a simple action (i.e. clicking a button) that could have been taken by each user.
Also I couldn’t figure out what you meant by the following; can you clarify with an example, please?
“Themes dependent on code … bound to the theme in a way … that introduced code breaking errors for a function already included in the WordPress core…”
davidkane
G’day Mike,
“If WordPress had dependency management built in..” – which is certainly desirable – but remains “If”.
Until very recently there were a bunch of them ThemeForest, I don’t want to name names. In a few cases it took several months to get some of those authors to respond to some of my clients with updates. While it’s certainly possible to remove dependencies, re-add thumbnails (in this example) and bypass regular users cannot and should not. Sure – TimThumb has the update tool and the code is being better managed – but it remains a PITA.
Not a bad addition to ManageWP BTW. The TimThumb scanner still requires a manual login on customer sites.
Mike Schinkel
“If WordPress had dependency management built in..” – which is certainly desirable – but remains “If”.
Absolutely. But it’s not going to happen, not going to be a priority for the WordPress core team if users don’t ask for it. That’s why I post about it, so users might read this, realize they need it and then ask for it.
“Until very recently there were a bunch of them ThemeForest,”
By example as I wasn’t asking for you to name companies or themes but instead give an example of the technical problem because your description in left me confused. Did you just mean the use of something like TimThumb? What was an example of something that was already in WordPress core?
davidkane
G’day Mike,
Understand the confusion now. No I wasn’t referring to the WordPress core at all. I was referring to theme developers incorporating things like TimThumb *instead* of using the core – eg “add_image_size” is a better alternative than TimThumb. As is Post_Thumbnails. Been there since 2.9 from memory – arguably added later than it should have been.
So nope. I’m not bitching about the core – I’m bitching about Theme developers including plugin functionality that at the end of the day led to, as I said above… “…a malware distributors wet dream”.
It would have been better to register a plugin with the theme as a regular plugin than bind it. Not WP’s fault.
Mike Schinkel
“I was referring to theme developers incorporating things like TimThumb *instead* of using the core – eg “add_image_size” is a better alternative than TimThumb. As is Post_Thumbnails. Been there since 2.9 from memory – arguably added later than it should have been.”
Ah, thanks for clarifying. As a side note, and I’ve worked with it extensively with the image handling functions in core what’s provided is confusing, inconsistent and incomplete so I can see why a theme vendor might have used something like TimThumb. It’s just really difficult to grok what’s going on with WordPress’ core image handling code.
That said I’ve been watching and it seems like things might be greatly improved in WordPress 3.5. I was going to participate in that but unfortunately a rush of last minute client needs got in the way.
“So nope. I’m not bitching about the core”
Didn’t take it that way. But I am. 🙂 Well, not really, just advocating for some attention to areas that have been either ignored or not considering important.
“It would have been better to register a plugin with the theme as a regular plugin than bind it. Not WP’s fault.”
Therein lies the problem. While WordPress focuses heavily on streamlining the UX for end users they’ve not empowered Theme vendors to do the same. If a vendor ships with a plugin that adds complexity for their users which means they may either loose the users or end up with significantly increased support costs.
If only WordPress had built in dependency managements… 🙂
John Zeiger
There is definitely a place for “themes” with built-in functionality but they shouldn’t be called themes (or even WordPress). This caused me some confusion a few months ago when I was looking for a turnkey solution for a client.
It reminds me of responses to posts on forums asking if the question is regarding a self-hosted WordPress site or a wordpress.com site; in essence 2 WordPress support communities exist. And for each “theme”, there is an additional WordPress support community which is much smaller and naturally less resourceful leading to a lot of unanswered posts. Even worse, unlike the wordpress.com support community, “themes” allow users to install additional plugins which may or may not be compatible leading to a lot of wasted time troubleshooting and disappointment when a plugin is determined to be incompatible.
Mike Schinkel
I’ve seen this debate come up time and again, but it’s always debated as a false dichotomy of “Should specific functionality go into a Theme or into a Plugin” when the better answer is for the WordPress to provide some leadership on the issue. Here are the 4 fundamental reasons this issue is a problem along with a solution for each:
1.) Lack of dependency management for Plugins – Neither Themes nor Plugins can say “I need this other Plugin in order to work” and then have WordPress automatically download and install it; it has to be a manual process and/or the developer has to implement it.
2.) “Infrastructure” Plugins are visible to end-users – WordPress pundits are constantly telling users to use fewer plugins, so if my Theme adds a Plugin it adds conceptual weight that the user sees and might get anxious about, or even deactivate or delete. If the user starts using a Theme that uses a Plugin that implements a custom post type and the user switches themes then WordPress could expose the plugin rather than disable it but otherwise, if only used by the Theme that required it, it should stay hidden.
3.) WordPress doesn’t provide shared “Libraries” – I think of Plugins as components that allow end users to add functionality, but as a plugin developer often what I need is a bit of developer functionality that I’d love to share with other developers but that no end user needs to know about. Remember “Decisions, not Options”; why should I burden the end-user if I use a low-level API library? I’d really like to be able to say “My Plugin or Theme uses this library, go download it when needed and treat is as an internal part of my plugin. And if some other plugin needs it to, great, let us share it.
4.) There’s no way to generically handle Custom Post Types across Themes – If a user wants to display events then they need to create a custom Theme template page for their Event plugin and/or their own custom event post type and if themes are switched, all bets are off. We’ve actually been working internally with our own library we call Conduit that I hope to have the time early in 2013 to promote as a way to handle this issue: https://github.com/getsunrise/conduit
If WordPress were to address these issues in a future release this problem could all but disappear because Theme and Plugin developers would have the tools they need for interoperability. Until then, we’ll just have two very sub-optimal choices. But I doubt the WordPress team will address this unless end users ask for it. They are far more focused on what 80% of end users want than what the probably 1% of WordPress users who are developers want.
Want this fixed? Make some noise! 🙂
stevewyman
Hi
Just wanted to add a further comment.
Happytables (as pointed out by Siobhan McKeown) is awesome. thats a whole industry idea if been working through. BUT its not a theme. its a complete end to end solution. it includes hosting etc and in a real sense is not a wordpress site/blog its a defined turnkey variant.
Very very neat. but i bet you cant add any old plugin you might like and changethe layout to what ever you wish. Nor should you.
WordPress is about flexability and in that context plugins should rule but for turnkey solutions the point is mute. Its down to the developers to chose the best functionality ofr thier system
regards
stevewyman
I very much prefer plugins. The use of seo in themes is a disaster for the newer flks that have not be exposed to the power of a proper seo pluing such as Yoast.
Theme developers would do their clients more good by including a commentary in their theme setup to alert people to the need for security plugins, sitemap plugins, seo plugins and chache plugins than to offer much less functioanlity just for “completeness”.
regards
Shameer Shah
Lovely post Tom. I think Siobhan’s comments sums it up for most people who simply want to get a blog started or have a light hearted presence on the internet without too much developer involvement and costs. I agree it’s a great platform, however, people need to be aware that sometimes upgrades of WordPress or their theme can disrupt functionality to some parts of the site and cause them to rethink about getting a developer involved. Of course complete overhauls and advanced branding will definitely require an experienced person to get involved.