WordPress Theme or Plugin

Last week, a fellow WordPress developer and I were having a conversation about a particular feature that he’s been contracted to implement for an existing site.

In short, he was trying to decide between introducing the new feature in the form of a child theme or in the form of a plugin.

It’s a question that I see raised more often than not, but I think there’s a series of questions that we can ask ourselves before jumping into writing any code.

Generally, it has to do with the true definition of a theme and the true definition of a plugin. Of course, there’s room for deliberation, but here’s how I normally see it.

WordPress Theme or Plugin: A Fun Flowchart!

Does This Belong in a WordPress Theme or Plugin

A professional flow chart documentation the decision tree for WordPress features.

Simply put, this is how I determine how I build features into WordPress-based projects:

  • If the feature has to do with a change to the core theme’s design, then it should be a child theme.
  • If the feature has to do with introducing or changing functionality, then it should be a plugin.

Now, this isn’t to oversimplify the process because I realize there is some overlap. After all, there are plugins that exist to change certain design elements – case in point – so there isn’t a hard line to be drawn, but I think there needs to be a significant point at which we know when something should be a child theme or a plugin.

Drawing a Line Based on The Feature

But this raises two questions:

  • If the feature in question has to do with design but should implement a menu option to toggle something, where does it belong?
  • And if you’re building a theme with even the slightest bit of advanced functionality, how should that functionality be developed?

I don’t have definitive answers, but I do have some opinions on this which are based on experiences that I’ve had with both client projects and work with 8BIT.

A Child Theme?

When you’re faced with needing to introduce a feature into someone’s existing theme, and the feature calls for something such as a font manager, that obviously has to do with design.

As such, the initial reaction is to think child theme.

The thing is, the core business need asks for a font manager. This means that there’s some functionality built into this request that assumes there’s going to be a set of data that must be managed.

Themes don’t manage data – they simply present it.

So, to that point, this is a grey area in which I believe it should be wrapped in a plugin.

A Plugin?

On the other hand, let’s say that someone wants to add three widgetized areas above their footer. Here, you’re dealing with introducing functionality that allows them to have a set of additional widgets but that functionality is already built into the WordPress API.

So, in this particular case, I’d say that you create a simple child theme that introduces a secondary container above the footer with three widgetized areas.

Ultimately, I think it comes down to this: It’s not enough to understand the difference in design and functionality. You have to understand the core business need and how it relates to the existing WordPress application.

The majority of the time, design-related issues will always be handled by child themes, and functionality will be handled by plugins. But in the off chance that they are not, make sure that you have a solid case for why you selected to go with one option versus the other.

After all, maintaining the project after a core theme is upgraded, the WordPress API changes, or the user installs a conflicting plugin can bring you back to working on it once again.


Join the conversation! 13 Comments

  1. It still doesn’t always give a perfect answer, but usually what settles the plugin vs. theme question for me is

    “if I redesigned the site or used a different theme, would I still need this feature?”

    If yes, it should be a plugin.

    If no, it can go in the theme.

  2. Interesting read – question: Why would you need a child theme to add 3 widget areas above the footer?
    Can you not just edit the template files?

    • You can do it within the context of the theme, but whenever that theme is updated, you have to re-introduce your changes. If you do it in a child theme, you’re far less likely to have to do that as you’ll have your own footer.php template file.

  3. I tend to split the difference when I’m doing client work. I split out most of the functionality in a theme (parent or child) into separate files in a /lib/ folder. those files can be easily transported to a new theme if need be, and it gives me less clutter from the client’s perspective in the plugins folder.

    also, it prevents clients from disabling functionality that their site requires.

  4. This sounds oddly familiar… =p

  5. nice article…

  6. Should a portfolio be included in the theme or added as a plugin?

    • This is a good question and it’s something that depends more on just the the idea of a portfolio.

      For example, there are certain features of a portfolio that can be relegated to functionality. These are things like custom post types, taxonomies, and so on. That type of functionality is usually left as a plugin.

      But if you go all-in, that is, you include all of the functionality and design – which includes not only functionality for it but also presentation aspects that you’re offering out of the box, then you’re looking more at a niche theme.

      So, imho, it really depends on the approach that you’re going to take with how you offer the portfolio.

  7. Hi Tom, good post. I have a question: I have a development company and we´re frequently using a couple of plugins I made for adding subscription forms, share buttons, and posts lists.

    So anytime we´re using a theme that doesnt include those widgets, we install our custom plugins.

    However, I was thinking that maybe it´s a good idea to wrap all those plugins into a master plugin like jetpack, where we could install just 1 plugin and activate the widgets we need from the options page.

    What are your thoughts on that? Do you think it´s appropiate to bundle everything into 1 plugin?

    I like the idea because our company would have an official plugin and our clients could enjoy cool widgets as a bonus. But I´m not sure…

    • What are your thoughts on that? Do you think it´s appropiate to bundle everything into 1 plugin?

      Unless you’re developing all of those plugins in house, I don’t recommend it as it creates a dependency model that’s going to be a pain to manage over time.

      One thing you may consider doing is dropping the plugins in the mu-plugins directory inside of wp-content. This is the “Must Use” plugins directory and they are ones that are required for everyone install of WordPress.

      That way, everyone is still getting the plugins that you require, but you’re not having to deal with the maintenance of keeping all of the dependencies up behind the facade that you’d ultimately create for all of them.

Leave a Reply