Why Themes Are Presentation, Plugins Are Applications

I recently had a conversation with someone about why I tend to favor working on WordPress plugins over working with themes, and the short answer is that I enjoy working more on application-type functionality rather than working on a design layer, and, as such, I believe plugins are applications for WordPress.

I’ve talked a little bit about this in previous articles:

In short, I tend to strictly view themes as the presentation of data whereas I see plugins as something that should transcend themes and offer functionality to WordPress regardless of what the current blog looks like. This isn’t a revolutionary Idea. Most experienced WordPress developers and designers feel this way, but I figured I’d offer my two cents on the subject.

In a way, plugins are like apps for WordPress.

Themes are Presentation, Plugins are Applications

First off, to say that I enjoy working on plugins more than themes is not to say that I don’t enjoy working on themes.

Standard For WordPress

Case in point, right?

But in all fairness, to hear me say this and to examine some of my previous projects – or projects that I started a few years ago and continue to maintain – would look as if I don’t practice what I preach, but the truth is experience is the best teacher.

To that end, I’m far more attracted to working with my team on lightweight, functional, good looking themes than I am on creating themes that provide some sort of hybrid between functionality and presentation.

And this is something we’re working on refining, but I digress.

At my core, I’m not a designer. I love seeing the work that other designers do and I love what the modern web supports, but I know where my strengths lie so I try to play to them.

Ever since school, I’ve focused primarily on building software, working as a software engineer , and then trying my best to carry that particular passion into self-employment and into startup life.

In the context of WordPress, this means that I gravitate more towards plugins.

Plugins Are Full Stack

So when I was talking to this one individual – he was another programmer, though coming from a different background – I tried to explain that themes tend to sit at the markup-style-and-JavaScript layer (well, the presentation layer), where as plugins are full stack.

Plugins Are Applications

Plugins are similar to full stack applications.

By that, I mean that in classical software development terms, plugins can be written as full stack applications.

That is to say that:

  • There’s a data layer that’s responsible for communicating with the database and managing data requested from and sent to it
  • There’s an application layer that is responsible for managing data that runs between the data layer and the application layer that provides business logic, error handling, and all of that fun stuff
  • There’s a presentation layer that’s responsible for making sure anything that’s presented to the browser looks good.

Naturally, not all plugins do this or need to this, but they are capable of it.

Themes Are Presentation

Conversely, themes are presentation layer – or at least they should be.

Admittedly, there are projects that I’ve worked on where I’ve baked a lot of application-esque functionality into a theme simply because it was possible, and for anyone who has read this blog long enough knows that I’m not a fan of “just because you can, doesn’t mean you should.”

So I’ve learned and am working to move away from that model.

WordPress Themes

Themes: A Presentation For WordPress

Instead, themes should be seen from the perspective that any functionality that needs to communicate directly with WordPress APIs should be done so within functions.php (and perhaps tertiary files located in an inc directory, but that’s outside the scope of what I’m trying to say).

The rest of the features are relegated to JavaScript, CSS, and HTML files.

The End Result

The article was mainly inspired by a lot of the conversation that I’ve seen recently about “theme bloat,” guidelines provided by both Automattic and Envato, and frankly my own thoughts and goals to have more maintainable codebases around WordPress-based projects an applications.

The challenge is, of course, the open nature of WordPress and how there’s no real way to enforce this across the board.

But that’s not really our problem is it? Instead, we can control how our work is organized and try to help others, but that’s about where the line stops.

22 Comments

So, playing devil’s advocate here…

What about so-called “App Themes”? I imagine an “app theme” to be where the theme relies so heavily on custom functionality, that it might as well be baked right in, rather than separated into a plugin. If you didn’t have the plugin installed, the theme would simply be broken.

Is it “ok” to bake that functionality into the theme in this case?

    Some examples here: http://www.appthemes.com/themes/

    WIthout the functionality, what would those themes be? So should they really be separated into theme and plugin?

      Short answer. Yep!

      There’s a good system for themes to make clear the plugins they need (http://tgmpluginactivation.com/) which those authors should be using. Also worth mentioning, I wrote a long post last week about why it is that those kinds of themes shouldn’t really be themes (http://pressupinc.com/blog/2013/07/what-belongs-in-your-wordpress-theme/). Summary: you put data into your theme and you no longer have a WordPress site, you have a That Theme site.

        Oh, I’m aware of TGMPA, don’t you worry (I actually have direct commit access on the repo).

        However, with something like an app theme, it is essentially *supposed* to be a “That Theme” site. That’s by design.

        Summary: you put data into your theme and you no longer have a WordPress site, you have a That Theme site.

        This is where I draw the line, myself. It’s about keeping data separate from presentation which is classic software stuff, right?

        But you’re right – and, like I mentioned to Japh – I think that it’s okay to have data in the theme as long as the user knows what they are getting into. And that responsibility falls on us (or our teams) to market it.

      I like David’s answer, but I don’t fully agree with it (no disrespect, of course!).

      Here’s why: if a theme a true app theme, then I’m okay with all dependencies being included as long as the customer knows they are locked into that theme.

      Otherwise, that’s when I think David’s recommendation of TGM Plugin Activation comes into play.

    I too am interested to hear some feedback around this question to.

    I just finished building a “theme” (read: application) that relied heavily upon custom plugins. And without these plugins the theme would break. In fact one of the plugins once activated didn’t DO anything. It simply provided a backbone for the theme to build upon by supplying classes/functions.

    I know it’s a grey/gray area that may never have a resolution. But some feedback would be appreciated.

      I think you’re doing it right. Unfortunately the big gap right now is that the WordPress core has no good methods to handle any kind of dependency, either between plugins or between themes and plugins.

      Brian Krogsgard wrote a great piece about why this is a problem recently, and calls out a few of the options we have while core doesn’t offer this functionality.

      When faced with a situation like this (and I have been faced with this a few times in the past), I normally setup several hooks that check for the existence of the plugins.

      If the plugins don’t exist, I’ll setup an admin notice or a similar message explaining the issue and then linking to support docs or to the plugin itself.

    I’ve always tried to separate “this should be a plugin” or “this should be a theme” in my head and I’ve come to think that we’re waaay past those times where you could simply categorize something in either black or white (if there ever were such times).

    I think that “Fundify” theme would a good example here. It’s a plugin and a theme – a combined solution. They built a plugin and a theme, they’re selling their theme on Themeforest and after they released the theme and plugin to the world, other authors used the plugin to build a different skin for that functionality.

    I believe that that’s the way the community should be heading and I think that slowly – it is. Just think Crowdfunding, Easy Digital Downloads, etc.

      That is spot-on. WooCommerce is another reasonable example: most of the better e-commerce themes leave Woo to handle the products, and just make the data look good. This way as a user you’re not constrained to the theme that came with the functionality you needed, be it crowd-funding or e-commerce.

      I’ve always tried to separate “this should be a plugin” or “this should be a theme” in my head and I’ve come to think that we’re waaay past those times where you could simply categorize something in either black or white (if there ever were such times).

      Agreed – but that doesn’t mean we can’t made the shade of gray a little darker (or lighter – whatever works for you ;).

      They built a plugin and a theme, they’re selling their theme on Themeforest and after they released the theme and plugin to the world, other authors used the plugin to build a different skin for that functionality.

      Yes – I do really like this model, but I still see that the relationship between the theme and the plugin still relate to the “what goes where?” in development.

      This eases that pain, but it doesn’t completely absolve it. At least, I don’t think it does – just my opinion, of course.

    So I think there are exceptions to every rule and, in this case, that’d be App Themes.

    But to be clear, I think that app themes should be explicitly clear in that they aren’t portable in that whatever configuration, customization, etc., that is does within the context of that theme is locked into that theme – basically, any plugins or whatever that are bundled with said theme are not portable to other themes.

    Which, of course, this raises the question is are app themes considered applications or are they just themes with advanced functionality?

For me it always comes down to what happens when you decide it’s time to switch to another theme. If theme author lets you know that switching will cause you to lose content, I’m cool with anything. At least you’ve been warned.

But using lockdown features in themes as selling points, without letting users know they could get into trouble, that’s bad and can easily lead to “OMG WHAT HAPPENED TO MY SITE!?”

    For me it always comes down to what happens when you decide it’s time to switch to another theme.

    Exactly – and this is why I think that if you bundle plugins with your themes or setup dependencies as such (as mentioned in previous comments), you need to have support documentation and you need to have notices or messages in the admin making it as clear as possible to the user.

    You don’t want to lock them into a theme (and I’ll openly admit that there are actually some decent business advantages to trying to do this), if they are going to eventually switch to another theme while wanting to maintain the same functionality.

I wrote a post, loosely around this topic, some time ago — albeit when I was a newbie in the game — and I could not agree with you more.

WordPress themes are a mechanism for presenting data. When a theme starts entering the realm of saving data, that is when we take a step back to see if there is a viable plugin solution, by a known source, for what we are attempting to accomplish. More than likely there is and, in the off case there is not, should we build one. The only time this does not ring true is when the data being saved is relative to presentation (logo image, background, type color, etc.).

This has not always been our modus operandi. Early on, we fell victim to the just because you can, doesn’t mean you should way of developing themes and quickly learned how potentially harmful this was to the WordPress user experience — especially when users switches themes and their content does not follow. Unfortunately, as you concluded, this is something that can not be policed, nor enforced. It is up to us to always “do the right thing.”

I see that themes are for design and plugins for functionality and content.

The guidelines provided by both Theme Review Team and Envato state that shortcodes are not supposed to be in the theme. If you create a shortcodes plugin that only works with your themes then the way I see it the shortcodes are still locked within the theme as you cannot switch themes without losing the shortcodes.

Theme Blvd Shortcodes is an example.

This discussion of a rating make me think how does a theme dependet plugin compare to an extention to anoteher plugin like WooCommerce.

So that themes still have a selling potential they will be need to add more customisations options and support more plugins out of the box like WooCommerce.

P.s. I believe it is the Theme Review Team that make the guidelines and not Automattic.

    If you create a shortcodes plugin that only works with your themes then the way I see it the shortcodes are still locked within the theme as you cannot switch themes without losing the shortcodes.

    Exactly. If you lock shortcodes into a theme in your plugin, what are you really accomplishing? Nothing. You’re just rearranging the initial problem which doesn’t help :).

    Also, as far as the theme review team is concerned, there’s one at Automattic and there’s one for free themes at WordPress.org. My bad for not clarifying this in the post. Thanks for the reminder, Ulrich :).

This is all very interesting. I understand the concept of form vs function, but there are plenty of caveats that defeat its mere purpose: to render a device-based presentation with features, functions and looks great (“The Theme”). For example, assume WordPress is a base model of a new car. Now, 99% of people who purchase new cars wish to add some sort of new features: a new stereo; custom seats; custom paint job; new tires; custom rims; mobile phone holsters; etc. the list goes on :-) For most of these features, the car should work perfectly with no problem whatsoever. However, if I buy a new roof-rack, should my rods be global and work with every darn roof-rack mount, bolt, cage on the Market? Should my designer-stitched seat covers fit EVERY seat manufactured or produced? This is why I feel SHORTCODES are ENTITLED to be theme-specific – some features accompany manufacturing of The Theme. Sure, swap out the tires – WP will still work. But if a User decides to switch themes, that’s their prerogative. If I buy a 2″ trailer hitch should it globally fit all trailer hitches? Should the manufacturer (Theme Developer) care about supporting other themes? WordPress (the car) still works! This is more about User Intent and long-term objectives! Hehe, my 2-cents. Would love to hear more thoughts!

    I think you make some compelling point especially around the idea of setting, say, global functionality versus, say, theme-specific functionality.

    As far as the car analogy is concerned, I don’t think it’s weak, but I think that it also only goes so far. By that, I mean you can also draw analogies that don’t work. For example, an analogy to the car stereo and putting in an after market stereo is similar to taking comment functionality and replacing it with another comment plugin (Jetpack, Disqus, etc.).

    Those plugins still transcend themes, but stereos don’t always do that – there are housings for stereos that may work in cars, but not in trucks, you know?

    Anyway, I digress.

    As far as your point is concerned:

    This is why I feel SHORTCODES are ENTITLED to be theme-specific – some features accompany manufacturing of The Theme.

    In an environment where things are as open as they are in WordPress where functionality can be blurred within presentation, then anything is fair game. I don’t know if I agree that the word “entitled” is correct, but it’s certainly allowed.

    Though it is the user’s prerogative to swap themes, it’s also fair to say that many people don’t know where to draw the line between where WordPress ends, a theme begins, a theme ends, a plugin begins, and where a plugin ends.

    To that end, I think that we have some degree of responsibility whereas we either educate the users (which no one reads the manual for everything), or we try to make it as easy as possible for them to understand what’s going on.

    Though, for some, themes are final and will be continued to be iterated upon for the coming years, others treat them like clothes and change them relatively frequently. When that happens, you have a lot of data that’s potentially begin mangled because shortcodes are being lost, stripped out, replaced, etc.

    In that case, I’d argue that you need some type of parent base theme, a generic plugin (but that’s a whole other discussion), or some type of huge warning that displaying on theme purchase and activation that warns the user what shortcodes it supports and then, on deactivation, lists the posts and pages that will be affected.

    Because, whatever the case may be for the users, I think we need to try hard to prevent them from hurting their data. In whatever means that requires of us, we should do it.

Leave a Reply

Name and email address are required. Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>