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.
Leave a Reply