Cancel

Jeff Chandler

Should Themes Have Plugin Functionality Built-In?

While monitoring twitter today, I noticed a few prolific theme designers agree with a point that Chris Pearson made today.

Now that I’ve built the platform, I see why Thesis can do plugins’ jobs more efficiently than the plugins themselves. There’s no comparison. – pearsonified

I think I understand the reasoning behind the statement. Instead of using a plugin that may have more functionality than is needed, ONLY the functionality that is needed can be built into the theme making more efficient use. However, I’ve always been a fan of the idea that themes should be about good design alongside flexibility while leaving anything that can be handled by a plugin, to a plugin. Sure, a theme that provides all sorts of plugin functionality built-in provides a ton of convenience, but the distinct difference between a plugin and a theme is that when the theme disappears, the plugin and it’s options are still there. The same can not be said for a theme. What’s the difference between putting a wall around me, and building in a bunch of functionality that is typically left to plugins? I don’t see much of a difference. If the theme is built in a way that semi-locks in the user, that theme is doing it wrong. But, I’m not the one with a theme business so perhaps I’m wrong.

At the end of the day, the user has to decide on whether they want convenience, or flexibility.

[poll id=”33″]
Category:
Tags: , , ,
31

31 responses to “Should Themes Have Plugin Functionality Built-In?”

  3. It’s a tough call really, because we’d probably all draw the line in a different place for what should be part of a plugin vs. what should be part of a theme. I would say if the theme is going to break without the functionality, then including it in the theme is generally acceptable. But I think theme authors should take it easy on that type of feature. Let the user choose their design from the theme, and their functionality from core or plugins.

    Create forum topic from comment

  4. I think it depends on the specific functionality you’re talking about. There are features that are nice to have as part of a theme, such as color/style options, layout/navigation options, and anything related to the design and specific to that theme. I’d also put some other things under the theme functionality umbrella, such as Analytics integration for example.

    But then there are things that make more sense as a plugin. For example, contact forms. There are many great ones available (both free and paid), and users probably prefer to use them with any theme they want. You wouldn’t choose to use a theme because it comes with a great contact form feature, would you?

    So i think it can go both ways, depending on the theme, the intended audience (mass consumption? or single client project?) and also depending on the feature.

    Create forum topic from comment

  6. I personally think that there should be some plugins that can easily be integrated into themes, whereas there are others that should be only used as plugins.

    For instance, a redirect to a Feedburner Feed is something that I think should be built into the theme rather than have a separate plugin.

    I think it really depends upon how many additives there will be. If it is simply a redirect, then by all means include it in the theme, but when it adds a feature like voting or something, then I think it should be a dedicated plugin, mainly because not everyone will want the voting feature, where the majority of people would prefer a redirect to Feedburner.

    Create forum topic from comment

  7. I think that another question that could be added to this discussion is: “Would it be better for themes that offer advanced functionality to be released as plugins?” This is a question I have been pondering the last week or so. It makes a lot of sense to me to have the functionality stored in a plugin. That way it can be easily incorporated into any theme.

    Create forum topic from comment

  8. I think a case can be made for both. For many new users, adding more and more plugins can get a little overwhelming and managing them can be as well. If a user finds a theme with all the functionality they’re looking for built-in, I think that’s an easier way for them to get up and running quickly. On the other hand, I can completely agree that having the functionality in the theme and not in the plugin can lead to potential problems as you change themes down the road. I don’t think it has to be one or the other, but I think it needs to be clear to the enduser the pros and cons of their options.

    Create forum topic from comment

  9. I was chatting with Jeff about this on Twitter, but I thought I’d add my thoughts here.

    As you become more familiar with the way WordPress works, you discover that there is very little real difference between plugins and themes. A plugin can easily take control over the rendering process, thus the plugin becomes a “theme”. Similarly, a theme can easily provide plugin-like functionality (and many do). So, the definition of what is a “plugin” or “theme” feature is very blurry.

    As a coder for iThemes, I try my best to not add features to a theme that is already very well supported by plugins. The reasoning for this is multi-fold: It reduces the complexity of the theme, thus reducing bugs and support needs. There’s no reason to rip off a plugin author’s work just to add a new bullet point to a theme’s feature list. It allows me to focus on creating new features rather than rebuilding features that have already been done and done well.

    Create forum topic from comment

  10. I tend to think themes should build in functionality if they can. Generally its more convenient, its more efficient and if you change themes you can always install plugins…it seems rather silly to say that someone would be out of luck if they switched themes.

    Create forum topic from comment

  11. @Andrew -That’s my viewpoint in a nutshell

    @Jared – It seems that way. I think there is a harmony that can be reached between themes and plugins but some themes appear to be moving in that opposite direction you mentioned.

    @Brian – Well, you mentioned analytic integration and although that can be handled by a plugin, it certainly is nice to have that as part of the theme. I’d group that specific feature into theme functionality, not so much the plugin realm anymore. This is where things start to get subjective.

    @Ken – I think that’s how it should be in a perfect world but when is the last time you experienced what you just described?

    @Michael Fields – That throws my mind for a loop. As I talked with Chris Jean, he mentioned Plugins can perform just about the same functionality as themes which turns this all into a mess for me. I thought there would be more of a distinction between the two but I guess not.

    @Chris Jean – This makes it pretty confusing to me and this must be the core of why so many themes have plugin functionality built into them since the two are roughly the same. I like your attitude towards theme development and what you stated is what I tried to state as my interest in the poll/post.

    Create forum topic from comment

  12. @Adam Baird – I just like the flexibility approach rather than the all in one approach. I’d rather switch themes while keeping most of my sites functionality in tact thanks to plugins rather than switching themes and having to go through that mundane process of finding substitutions for what the theme provided.

    Why should a theme do anything more than be a good design with flexibility?

    Create forum topic from comment

  13. I believe themes are all about the aesthetic look and general layout; and, plugins are all about functionality. Of course the two are not mutually exclusive, they should work well together and when doing so create something greater than either by itself.

    Adding functionality to a theme is all well and good, provided it is not done for the sake of doing it. If the premise of a theme requires the functionality of, for example, a menu plugin to accomplish its end goals then it is obvious to me that the functionality should be included. Do themes need to include Twitter, Facebook, or anything similar (again, as examples) I think not, there are plenty of very good plugins that manage these functions all too well.

    Just like @Brian commented:

    … depending on the theme, the intended audience (mass consumption? or single client project?) and also depending on the feature.

    Create forum topic from comment

  14. As a user, I would prefer the functions built into a premium theme.

    I get a plug-in and make a donation (usually). But I know I cannot really count on the dev to support my plug-in or to keep it current with wordpress. I just have to hope she does.

    It is unrealistic of me to expect devs to keep plug-ins updated when most of us just leech off their kindness and never send in a single dime. Eventually devs have to get real jobs that pay them for their expertise.

    When I buy a premium theme with functionality built-in, I am better assured of support and that it will upgrade as WP upgrades.

    As a user, the fewer things I have to download, install, pay for or leech off of as individual items, then the better. If it is built into the premium theme then I get functionality, support, upgrades, and I save time. If I don’t want the fuctionality I can turn that feature off.

    Devs deserved to be paid and Users deserve long-term confidence in the product. Semper Pax, Dr. Z

    Create forum topic from comment

  16. I prefer to keep functions in plugins, so that your site will keep working when you change themes, but I understand where the developers who want a leaner site with less script redundancy are coming from when they prefer to build in just the functions they need.

    Fine if you’re never going to change themes or can somehow foresee all the functions you’ll ever need or will still be around to do all your own updating as WP adds new things like widgets, tags, and post thumbnails. Not so good otherwise. (And for those of us who aren’t developers and don’t plan to be, not really an option.)

    Themes with theme options–which means, in essence, built-in plugins–are handy for the people with no knowledge of the way WP works, but problematic for people who have been with WP since the early days. (I wrote about this after my first encounters with themes like this, which were hair-tearing experiences.)

    Create forum topic from comment

  17. After lifting under the hood with Buddypress themes, I’m facing this issue now.

    I’d prefer it if the functiionality in themes was deselectable in files that could either be deleted or simply not loaded (to remove load time issues). That takes greater effort and pre-thought, but it would be appreciated. If functionality in themes were essentially plugins for themes, they could be appropriately deactivated. It would also facilitate themes having an api for plugins that others could build from.

    In my case, I’m taking a BP theme, putting it in a Hybrid theme and then changing the functionality pretty extensively through plugins that will need to act differently with the theme.

    Although I hated them at first, I’ve grown to like hooks and unless someone has a better idea, I’d rather look through functions.php than search all over creation to fix stuff.

    Create forum topic from comment

  18. @Jeffro Not that often to tell the truth, but as I progress in my skill level, I do spend a lot of time considering the issue, and work toward do so.

    For example, I have some functionality that plugins typically handle (featured post front page slider) but doesn’t suit the need of the theme, so I put the functionality in the functions.php. I’m considering offering the sollution in a plugin if it seems worth it in the end, so I’ll put a check in the theme’s function to check for the plugin and use the plugin if available (and check version). Certain functionality (like this) only makes sense if the theme uses certain template tags or hooks, so the plugin should likewise check for theme support.

    (With add_theme_support( 'post-thumbnails' ); in WP 2.9 it seems as though this could be a beginning, perhaps as a place to open registration of functionality to other plugins and themes (though it could get messy, either with name collisions, or millions of semi-identical feature names). Perhaps some variant on the wp_enqueue_script/wp_enqueue_css functions to handle versioning and whatnot but that might be overboard.)

    I’m also open to including other coders’ plugins (with permission of course) right in the theme and to defer any updates to the plugin in the same way.

    Anyway, I mean that I’ll work towards that perfect world in my own code atleast ;-)

    Create forum topic from comment

  20. From a development standpoint it makes more sense to separate plugins and themes for the same reason it makes sense to separate css and html. Howver it really comes down to the end user.

    Anyone who’s even capable of having this conversation is on the savvy side when it comes to WordPress. We’re not typical of the average WordPress user. You and I can install and remove plugins in our sleep. It still confuses many an average user.

    For many people it’s simply easier to have everything inside the theme. One thing to install. One point of contact when support is needed. Even bundling plugins with a theme adds a layer of complexity that’s more than some people want to deal with. Plenty of people still don’t realize you can search and install plugins directly through the admin side of WordPress.

    I don’t disagree with the idea that if it can be a plugin it should be, but you do have to consider who will be using your theme. It may not be better from a development standpoint, but I’d bet most end users would prefer everything be in the theme since it means less for them to deal with.

    Create forum topic from comment

  21. Depends.. On what functionality you’re looking for. Quick example – breadcrumbs. Breadcrumbs should be built into themes, page navigation too. Twitter widgets, contact forms, etc should be plugins, because they’re not essential. And don’t ask me to define essential ;)

    That’s my humble ;)

    ~ @kovshenin

    Create forum topic from comment

  22. Some stuff can be built in but most should not be. The typical “SEO” stuff can probably be built in, breadcrumbs also. And Chris Pearsons statement is mostly egobased I think. Each new addition to a theme adds complexity and update requirements. Also potential conflicts with plugins that add the same feature and more.

    Create forum topic from comment

  23. How about, WordPress looks in the theme folder for a plugins folder and treats that exactly the same as the main plugins folder. If there are two plugins with the same name, the one in the main plugins folder overrides it.

    That way everything you need is bundled, plugins within themes can be upgraded separately from the theme as a whole using the normal process, an alt version can be released, or simply created by the user, and maintained separately so theme updates don’t break the update.

    What else could you possibly want?

    Create forum topic from comment

  25. @Steven Bradley -Well said.
    Many users want to be able to focus on writing content for their websites and not learn the ways of PhP, those deeper mystical ways, where many are called but few are chosen.
    The avergae user just wants to run a blog or site with the fewest possible obstacles (i.e., installations) to contend with.
    Semper Pax, Dr. Z

    Create forum topic from comment

  26. Themes should not have plugins built into them. If the theme author whats to have an enchantment to go along with his theme though, they should be released with the theme and the user would just activate the plugin to get that functionally that the theme author envisioned. I did that with my personal theme at first, and I realized if and when I would make a ‘public’ version of it I would have to take a lot of functionally of it to make it more universail.

    Themes should be designed to be universal with no strings attached.

    Create forum topic from comment

  27. Before WordPress 2.8 when the theme installer was added, it was simple for theme designers to include a plugin with a theme they developed. That way they could have the best of both worlds: functionality with a plugin, and great styling and integration of it into their theme. If you think back a year ago, many premium themes came with at least one or two plugins packaged with them. Now with the built in “upload a theme” feature, it’s just not feasible to include plugins in order for people to use the theme installer (which they will). You can’t skip of the features, because there is competitive pressure to include features in order to sell (or give away) themes, so the alternative is to build the features into the theme. It’s a reality that is created by the software that we use that does affect how themes are designed and distributed.

    Create forum topic from comment

  28. I see both points of view, but when it comes to plugins that affect styling — and yes, that would include forms (though forms could be switched out if a use wants more features) and getting the theme to work right “out of the box” so to speak, I think that building the options into the theme really makes sense.

    As others have stated, particularly Bill, Steven and John — the more things that the user has to install to get stuff to work — or the more things that have to be updated, the more hassle.

    Case in point. I tons and tons of staging sites on my MAMP server running on my Mac. This way I can have a million different installs of various things and keep trying stuff out, breaking stuff, etc. However, I also like to have a mirror of my current sites, for development purposes. When it comes to creating a local mirror, I have to install WordPress, upload my themes and plugins that I use on my main sites over, activate them, make sure the settings are set correctly, etc., just to get to the point that I can have a good mirror. Now, granted, I can (and often do) just import in the MySQL file and mirror the databases, but even so, if I’m setting up a new testing environment, it’s a lot of work.

    And that’s just for one theme. You add in other stuff into the mix, and it just grows from there.

    Plus, what happens when the person who made your really awesome contact form disappears off the planet. Or your plugin for a certain graphical element isn’t updated and breaks in future versions. My point is — for stuff that you see visually, I think it does make sense to build it into the theme when possible. Sure, make it an option to turn it off or to override, but build it in so that the out of the box experience doesn’t suffer.

    When it comes to stuf like SEO, Google indexing, and other backend components, I’m a little less sure. I think building in a option for a feedburner URL or adsense code makes sense, those plugins are typically just injections into the header files anyway — but for more in-depth stuff, it might not make sense to make it all about the theme.

    Really though, I think that the future of WordPress is shaping up to be less about everyone change themes like they are socks and more about what Drupal is doing, which is to package different distributions around a certain concept. So you have your Thesis WordPress distribution that is your whole site in a box. And you can edit the CSS and other stuff and you can add things to it but the theme becomes a fundamental part of the backend, not merely a component. That’s how real content management systems work and if WP moved in that direction, it would be a good thing.

    Create forum topic from comment

  29. I see both points of view

    This is really all I’m saying. There’s more than one point of view here and it’s going to be based on who’s using WordPress. There’s no question that if you want to change themes, while keeping all your functionality, it makes more sense to have that functionality be coded as a plugin, but is that how most people are using WordPress. Often a change in theme means a change in functionality too.

    When clients approach me to develop a theme they don’t ask for functionality. They tell me they want a theme with a calendar. To them that calendar is part of the theme. The see it as part of the design. Later they come back to me wanting a new theme because they don’t like how the calendar looks or they want a theme that has social media links instead of a calendar. The average user of WordPress doesn’t necessarily see the difference between theme and plugin.

    Other clients might come to me looking to have me customize a theme they found. Often they chose the theme, not because of the layout or color schemes, but because it included the calendar they wanted. Again they see everything as the theme and not necessarily a mix of theme and plugin.

    The above is not typical of everyone, but it is typical of a certain class of WordPress users.

    You can reduce all your WordPress files to be nothing, but a bunch of hooks and widget areas and a css file to style everything. That would make your theme very flexible. It would also confuse the majority of WordPress users who’d be wondering why when they installed the theme it didn’t look like the demo they saw. Are they going to use your theme that requires them to add plugins and widgets or are they going to use the theme that looks pretty much like yours, but has all the functionality built in by default?

    I think Christina is exactly right in saying

    that the future of WordPress is shaping up to be less about everyone change themes like they are socks and more about what Drupal is doing, which is to package different distributions around a certain concept.

    I think you’ll see more themes developed as turnkey solutions for a specific industry. As an example think of a photographer who wants to use WordPress mainly to show off their portfolio and have image heavy posts. That person will need to have all sorts of image gallery functionality, etc. that right now exists as a plugin.

    Some theme developers will create a design and bundle it with those plugins. Other developers will put the functionality directly in the theme. Like it or not the theme with the functionality built in is going to be the easier one for most people to use and is going to be the one that gets recommended more often by those people.

    Again that’s not necessarily true of everyone, but it is true for a large group of WordPress users.

    When someone using that theme wants another look for their site they’ll come back to the place where they found the theme and discover a series of skins (a new css file? a child theme?) that exist to change the theme’s look.

    Again I’m not arguing that it doesn’t make sense to code the functionality as a plugin instead of placing it directly in the theme, but it does add one more level of complexity for end users and one more place where they can make a mistake.

    Don’t Make Me Think.

    Those of us commenting here don’t have to think about adding a plugin. The average end user of WordPress still does. Ultimately our goal as theme or plugin developers is to make their lives easier. For some that will mean coding functionality directly into the theme and for others it means separating the functionality into a plugin to make the theme more flexible.

    Decide who you’re developing for and code accordingly.

    Create forum topic from comment

  31. Here is the problem with putting lots of functionality in a theme… BUGS. Nothing is ever BUG FREE.

    Unless the theme has a rock solid upgrade capability built in… i’ve yet to see one that does… the more features that are built into it the more of a pain in the ass it is going to be to apply bug patches when they are needed.

    Themes on the other hand are not so simple to update. Themes are designed to be hacked away by the user if they so desire… building functionality into the theme makes this impossible as it eliminates the capability of doing updates to the functionality.

    The utopian scenario is a parent/child theme setup where you can upgrade the parent without impacting anything. But good luck getting the average users NOT to edit the parent theme directly. As soon as they do, it makes upgrading pretty much impossible without losing their changes. That results in pissed off users, even if it is their own fault.

    Plugins are designed to be updated frequently because the more complex the functionality, the more bugs and the more updates that will be required. They are designed to handle this.

    With plugins, the user doesn’t typically edit the plugin. They can quickly and easily receive updates and fixes via the plugin automatic update functionality.

    That is what plugins are designed to do.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.