Where WordPress themes end and plugins begin


A weekly editorial, from Ryan Imel the editor of WPCandy

One of the highlights of my WordCamp MSP 2010 experience was meeting and chatting with Ptah Dunbar a bit. Ptah is a consultant and WordPress developer at DevPress and contributed a good deal to the menu system in WordPress 3.0. He was at MSP to talk about theme frameworks—specifically his, WP Framework.

While we chatted, I asked his thoughts on a number of things, but one in particular stuck out. My question was: where should themes end and plugins begin? How much can a theme do before it is considered too much? Theme developers and plugin developers seem to give differing opinions at times. I was interested in Ptah’s thoughts because he has developed a number of themes and plugins.

His answer was pretty straightforward: if it’s something central to the functionality of a site, something that will need to remain when the theme is changed, it should be in a plugin.

And that answer resonated with me.

Rather than in our functions.php file, I’ve moved them into a plugin called WPCandy Functionality.

I’m not altogether interested in disecting individual themes to say which involves more plugin functiaonlity over another, and just how much should be there.My thoughts are mostly focused on my own work, and how I prefer to build websites. I honestly feel that I’ll be changing the way I approach WordPress sites now.

Take WPCandy, for instance. We have a decent amount of functionality that is pretty central to the site’s operation. We have custom taxonomies that help us to organize post content. We will soon have custom post types too (wink wink). We have a number of functions used for displaying this custom information too—so important we’ll need all of them even when we update the site’s theme later.

So rather than contain all of these within our theme’s functions.php file, I’ve moved them into a plugin called WPCandy Functionality. Now I have all site-specific functions required for the site in a safe place that I won’t lose during a future theme change.

And it feels right.

I’m reminded of Joost de Valk’s post and my response a few months ago, and the subsequent discussion afterward. I think I understood the issue before, but it was after talking with Ptah that it really “clicked” for me.

What about you? Do these thoughts “click” for you too? What is on your site that would best serve you in a custom plugin?

22 thoughts on “Where WordPress themes end and plugins begin

  1. Lots. 🙂

    I’m actually distressed over the number of “do X without a plugin! Stuff this code in functions.php!”

    How about stuff the code in your own custom file in the mu-plugins folder? It works on single WP installs too, would stay on upgrades and more importantly woudl not get removed when you switch themes.

    • Agreed. I see my time focused on functions.php as a time when I was more focused on themes, rather than WordPress sites from a more holistic stance. As I learn more and more about how things should ideally work, I’m making small tweaks like this.

  2. Ryan,

    On WPBeginner, we too have a plugin that has all the functionalities for the site to function. It helps a lot when making changes because we won’t lose anything for any reason.

    But I would like to hear other’s thoughts on how they deal with this matter when working with clients. Do they create a separate plugin and upload it?

  3. I honestly had never thought about this, but it makes total sense. Thus, I’m actually taking steps to separate some functionality from the theme itself on a site I’m developing today. I was going to use the Genesis theme’s built in SEO features and instead I’ll be trying out Platinum SEO (as recommended by Mert at WordCampMSP) to separate the SEO functionality from the theme itself in case I ever change the framework/theme.

  4. While I understand your idea of a plugin sticking in time and staying when you change your theme, I have a slightly different opinion:

    With the latest versions of WordPress, theme development has changed a lot; child themes have been introduced, and we have seen different theme frameworks emerge and being developed by famous developers.
    These frameworks, and the parent/child theme system altogether, allow everyone to develop a parent theme, a framework that will contain all the core functions of the website, and then the design itself can be created within a child theme.
    Thus when changing to another design, the parent theme stays, only the child theme changes.

    That solution works for me, and I tend to use less and less plugins and add more and more options to my framework (and of course, I don’t “stuff” everything into functions.php. I try to organize all these functions into different files being called by functions.php). These options are either activated or deactivated depending on the design.

    I believe both solutions are fine, and it must be the choice of the developer to stuff his options into his theme or into plugins. Don’t you think?

  5. Maybe I’m over-simplifying things, but:

    1) For anyone who has no intention of ever changing from one Theme to a different Theme, it really doesn’t make much of a practical difference, and

    2) For everyone else: functionality that involves how content is managed is Plugin territory; functionality that involves how content is displayed is just fine in the Theme’s functions.php file.

    Thus, anything involving custom taxonomies, custom post types, and the like should probably be in a Plugin, so as to preserve content management between themes.

    • I would agree, Chip. Re: 1), I would say that since users likely don’t ever think beyond one theme at a time, it’s the job of developers to think for them, and build manage-type functionality into plugins. Otherwise we’re just setting up users for struggles later.

      • Yep, I agree, too. But then, such users would be in point 2), rather than in point 1). The first group would be the roll-your-own-Theme crowd.

        Any Theme intended for distribution would, by nature, fall into point 2) – and designers of such Themes should *definitely* take into account the portability of managed content. That portability essentially requires that content-management be implemented via Plugin, rather than via the Theme itself.

  6. A couple theme frameworks off the top of my head:

    Platform Pro by PageLines
    Genesis by StudioPress
    Thesis by DIY Themes
    Headway 2.0 by Headway
    iThemes Builder

    I agree with jeherve from above that Child themes will protect your information from being overwritten with new framework updates.

    Also, isn’t part of the rationale for including plug-in type stuff in the Child theme tie to the amount of plugins slowing down website speed?

  7. It is not the amount, but rather the code quality, of Plugins that will impact site speed. The same number of plugins will impact site speed exactly the same if those same plugins are instead copied into functions.php.

    • Anything in particular we should check for to determine the quality of the code? I am guessing that the heavily used plugins are well coded, such as All In One Seo, Akismet, etc?

  8. Agreed.

    It’s as simple as asking “Will I still need this feature after the theme is changed?” If the answer is yes, then use/put it in a plugin.

    I can see how from a business perspective it can be more advantageous to add plugin-area functionalities to a commercial theme, though, more selling points and control of what people can use with their theme. However I think a clear separation is still the best practice here.

  9. I totally agree that it makes sense to segregate your functions between plugins and your functions.php file. One thing that really works against this from a theme developer’s point of view is WordPress’s built in theme uploader. Before that was implemented, it was a simple matter to package a theme with a required plugin or two. Now most users never unzip their theme folders before uploading. This situation has caused more of the functionality that would normally be in a plugin to be included in themes for simplicity’s sake. I’m in no way arguing that we remove the uploader, but rather this was an unintended consequence of that feature

    • Excellent point Bill. So the question is: how can theme developers make it easier/more acceptable to enable upon installation?

      Perhaps setup/settings screens that trigger plugin installations? Or more portable feature sets in general, where certain elements are only turned on when a plugin is active.

      If I had to guess, anyone who creates and distributes themes will cringe hearing my ideas here. 🙂 If I had to guess the number one reason themes are built the way they are is for the sake of the end user, who may not really be used to thinking in terms of plugins, or at least in terms of how plugins should (or should not) interact with themes.

      • I used to name my zip files things like “unzip and upload separately”, but I finally just caved in, edited the plugins and added them via functions.php. I’d love for their to be a straightforward way to manage required plugins.

  10. I thought of an interesting thing in relation to this and my web comic: When deciding the best method to display it, I researched quite a bit and discovered ComicPress. Several web cartoonists swear by it, so I looked into it. I was immediately skeptical, because ComicPress is a theme that displays web comics. However, what if I ever wanted to change my theme? I’d have to find some other way to display my web comic.

    I used Michael Sisk’s Webcomic plugin for a while, and now I use stripShow, which is also a plugin. I don’t think there’s necessarily anything WRONG with ComicPress, but I wouldn’t use it because of the original point of your post.

  11. Pingback: Community links: Nacin’s first year edition | WPCandy

Comments are closed.