Plugins and themes are different animals

7 Comments

A weekly editorial, from Ryan Imel the editor of WPCandy

The more I think about it, the more I agree with Joost de Valk’s post from last week discussing themes taking on functionality that is better left to Plugins.

What I’m thinking is that themes are different from Plugins, So different, that it’s changing how I approach themes and Plugins, and how I determine whether they are quality or not.

I want to tread carefully here, because I release neither themes nor Plugins. I’m a developer, but not one who distributes anything to the public.

Changing themes, whether to another custom developed theme or from one commercial theme to another, is usually a pain. Why? In my experience, it’s usually due to the necessary porting over of options, settings, and sometimes content. It takes effort to make sure that the new theme will not only work, but be personalized as well as the last theme was.

It has me wondering how much of the functionality I have built into WPCandy shouldn’t be in a Plugin rather than a theme. My custom taxonomy settings, for instance. I will absolutely want to bring them along with me when I update the theme.

An analogy

My background is more in front-end development than backend development, so forgive the following analogy.

If a website’s HTML is written well, it will turn the page’s content into meaningful, machine-readable stuff. Then we use CSS to turn the machine-readable into the human-readable. Ideally the original HTML should never need to change. Site redesigns should only need to change the CSS, so the HTML can stay somewhat sacred, traveling with the site as it evolves and grows.

This same principle, that of keeping content sacred and separate from the way the site looks and feels, can apply to themes and Plugins.

This same principle, that of keeping content sacred and separate from the way the site looks and feels, can apply to themes and Plugins.

Using this analogy, the database takes the place of the HTML. Rather than creating new fields to hold the same content, time and time again, wouldn’t it be best to have one dedicated spot that any interested themes (or Plugins for that matter) can call upon?

Most commercial theme’s options ask for social network and analytics information, for instance. This is content that’s sacred to the site, and it likely won’t be changing any time soon. What if—if—a Plugin had such popularity that theme developers chose to use its information over its own options. Perhaps a Plugin could exist which would extend the profile options within WordPress itself, something themes and other Plugins could check for before adding and requiring its own version of the same options.

What if, along with design, it became standard that every commercial theme was scrutinized for any additional options it includes that don’t directly effect the appearnace of the site? How would themes do?

The counter argument

I understand that theme developers are, for the most part, working for the lowest common denominator. That is, their themes must be easy for all users to use. The more moving parts (or activated parts, I suppose) the more difficult it is for the average user.

But these same users are the ones most likely to switch themes without playing it safe and copying over their theme options. So really, supporting a Plugin like I’ve described would make it easier for interested users to test out new themes—maybe your theme.

Nice, but how?

All of this will be lost without solid options to move forward with.

I see two that are most likely.

One, WordPress evolves to the point that more of these types of content options are build into the backend.

Two, a kick ass Plugin (or family of Plugins) is created that is so loved and so adored by its users that theme companies are uncontrollably drawn to include them in their themes.

Anyone who has been following WordPress development for more than a week knows that the first option won’t ever happen (and it’s a good thing that it won’t). A Plugin is far more likely.

So what would it take to start up Plugins—small, bite sized, targeted—to begin taking over the options from commercial WordPress themes? Any ideas? Any takers?

7 thoughts on “Plugins and themes are different animals

  1. I think there are different use cases where functionality heavy themes make sense and other times where they don’t.

    For typical blog users, I think functionality heavy themes aren’t going to make sense. You most likely are going to change your theme frequently, or at least more frequently than most business users. So you probably want things to be more flexible and portable.

    For using WordPress as a CMS in a business environment where you are creating a business web site, you most likely aren’t going to be concerned about not being able to switch your theme on a whim.

    Chances are as a business you probably hired someone to developer your site to specific specifications, and a functionality heavy theme with lots of options, etc. probably provides the best solution for this use case as not only does it mean less plugins installed but it also means you have less sources for receiving support.

    If the theme does a lot of the functionality some plugins have, as a business you don’t need to go to countless different sources for support on various functionality issues. You may just have to go to one… the theme developer that created the theme.

    I have changed my position on this and I think as long as the theme developer puts out a good product, and provides top notch support… by all means give me functionality that can replace a plugin. If it does the job good or has the ability to be turned off (ex. SEO options that can be turned off in favor of a plugin) then bring it.

    Businesses don’t change their theme on a whim. They are usually custom designed and created for them. Obviously they may involve customizing an existing theme. But they aren’t the same use case scenario as a blog user who may use a stock theme and swap them out whenever they feel like simply by activating another.

    Take ecommerce for instance. I’m becoming more and more convinced that ecommerce for WordPress makes more sense as an advanced theme framework rather than a plugin. Why? Because it’s presentation heavy. Category pages, product pages, shopping cart pages, account and order history pages, etc. Doing that as a plugin becomes problematic and difficult to do and it usually has to be done via the plugin having it’s own template system. A theme framework on the other hand could accomplish it in a more graceful manner… and then you could sell child themes for it.

  2. There certainly isn’t any hard and fast answer. I wish I could say it was as clear cut as HTML vs CSS vs Javascript (but even that line is blurring).

    I tend to build themes as simply presentation and leave all functionality to plugins. Or I at least think about which functions in the site would definitely need to persist beyond a single theme.

    I think Carl brings up good points about different scenarios allowing for the theme to carry functionality. And I’ll expound on his mention of theme frameworks as I think this is the direction to go.

    A theme framework (functions) is the core being of the theme. It includes everything a theme should need and more. Stick that framework inside of a parent theme (template files). Now your theme functionality, theme presentation, and extra functionality (plugins) are all separate.

    Then child themes should be built to change the look. Ideally a site would continue to use the same framework and parent theme and simply swap out child themes. This is the most future-proof method and certainly preserves the HTML.

    So, I vote for frameworks and parent themes. Then I vote for plugins that are so well coded, adopted, and supported that they become the de facto plugin for its purpose. This is off track, but I wish the community was more concerned with making one bad ass plugin than a hundred crappy plugins.

  3. Rather than themes with plugin-like features, or plugins that have their own templates, I’d like to see a tighter integration between themes and plugins.

    I don’t really want breadcrumbs built into a theme, but if I install a popular breadcrumb plugin and it automatically loads them in the theme and they are styled to match the theme, that would be ideal.

    Or since the most popular eCommerce options for WordPress happen to be plugins, why don’t they have a tighter relationship with commercial theme developers so that there are really polished shop themes out there that integrate with these plugins?

    I think integrating them offers the best deal for the end users. If they don’t want a feature, skip the plugin and the only overhead is a bit of CSS and maybe a template tag or two. But if they do want that feature, they can install a plugin and be more confident that it will be better maintained and be more flexible than if it was just bundled in with a theme.

    I agree with Carl that these are probably bigger issues for small and medium sized websites though. A larger site probably doesn’t make big changes as often and can hopefully devote more resources to maintaining their site.

    Hey, why aren’t you releasing any themes or plugins? Maybe you should do the same feature as a theme and a plugin and write a follow up on the pros and cons of each. :)

  4. You know, Matt and many of the other lead WP developers have been wanting to tackle part of the problem for a while — community-built plugins.

    Big problem #1: 18 billion crappy plugins (with a few quality ones) that offer the same or similar functionality all with various methods of implementation. Theme developers end up having to support all of them because users usually come to the theme dev to figure out how to implement them.

    Solution for big problem #1: Community-built plugins that theme developers can get behind and support.

    I’m not saying this is the complete answer to all the issues, but it’s a start. The community has to support it.

    I’m not a fan of options-heavy themes though (despite having built a theme called “Options” at one point in the past). But, there are certain things that are so heavily tied into themes that it just makes sense to include them within a theme. For me, this usually includes anything that a theme user would have to manually edit the theme templates to use.

    Themes that include options for things that are obviously plugin-type features should at least allow users to turn the theme features off.

    • Everything you said could be applied to themes. There are 18 billion crappy themes out there. So is the answer community developed themes? I think not.

      I’m actually surprised WordPress has not spiraled out of control given the vary chaotic environment in which most open source software is produced. Luckily it’s less “open” then promoted as it is controlled and run pretty tightly by the people that run the project.

      I think the answer is high quality solutions developed and support by professionals. Be it plugins or themes.

      If you don’t want to pay… go ahead and use one of the countless free solutions. But as with almost anything, quality and reliability typically comes at a price.

      • Just to reiterate what I wrote in my previous comment: “it’s not the complete answer to all the issues…it’s a start.”

        Community-developed themes? Yes, they’d be great. It’s a project that I could get behind. That’d definitely help bring some more quality to the theme repo. Obviously, these community-built themes wouldn’t fix all problems.

        You’ll have to do a lot better to convince me that community-built plugins wouldn’t be beneficial, but I could be swayed with a good argument against them.

        Solution #2: Companies with professional developers and designers build awesome plugins that make the 18 billion crappy ones useless.

  5. Pingback: Where WordPress themes end and plugins begin | WPCandy

Leave a Reply

Please note that WPCandy is a moderated community.

Your email address will not be published. Required fields are marked *

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>