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.