Most experienced WordPress developers will likely make the case that themes are for presentation and plugins are functionality. I agree with this and it’s something that I try to take into account with each project that I work on.

That is, whenever I have a project that consists of some unique functionality, then I’ll build out said functionality into a plugin and then either advise the customer or the user of the theme to download the plugin (for which there are some great tools available for this) or I’ll include it in such a way that the theme will include it and activate it.

Honestly, I’m not a big fan of the latter – it assumes the user doesn’t already have a version of the plugin installed, it creates a dependency that’s harder to manage, and it’s activating something that the user may not want activated even though we may see it as something that’s crucial for the site to function properly.

This is something that could probably be argued ad nauseam and though that’d make for a lot of fun in writing up a blog post and chatting in the comments, that’s not the purpose of this post so I digress.

Instead, it’s to offer up the idea that perhaps there are shades of gray as it relates to building specific functionality for highly niche themes.

WordPress Theme Extensions

As mentioned, it’s relatively straightforward on how to build and manage WordPress themes and plugins. The rule of theme is to segment based on presentation and functionality and then give the user a heads up what plugins will work best with the theme.

But not all themes are created equal. Some are highly, highly niche.

Case in point: I’ve been working on one lately that’s extremely niche (that I’ll talk about later). It has a number of features that are completely unique to the theme and will most likely never be used in another plugin; however, said features cross the line from presentation into a functionality.

So when we get to a point like this, what do we do? That is, what do we do when we have components for a theme that are best written as plug-ins but are so specific that their only use case is within the theme itself?

What Do Plugins Do?

If we take a step back and look at what the plugin economy is doing, we have the idea of extensions. That is, we have plugins for plugins, right? These are specific pieces of software that depend on another piece of software to run and that will only run under those conditions.

The Easy Digital Downloads Extension Library

The Easy Digital Downloads Extension Library

If we were to borrow this idea with respect to our themes, does that mean that we have an idea for theme extensions? That is, pieces of code that are written for specific themes and that depend on said theme?

Good programming practices generally urge us in the direction of making our code as modular as possible and segmenting areas of responsibility – most people who have been programming for at least some time know this.

On To Theme Extensions

As such, when it comes to the idea of theme extensions, I think a strong case can be made that anything that’s outside the scope of presentation and in the arena of functionality should be a plugin, but if it’s only for a specific theme, then it should be considered a theme extension.

The Array Toolkit Plugin

The Array Toolkit Plugin (For Array Themes)

If older versions of PHP supported namespaces, then I would say that the code would be in a namespace directly related to the theme. Instead, for now, I’d say that all of the classes (or functions depending on how you’re writing the code) should be prefixed with the theme’s name – you know, the whole “poor man’s namespace” idea.

This still raises the question as to if the extensions should be bundled with the theme or not. I think that this can be answered by asking the following question:

Is this code required for the theme to function properly?

If the functionality is required, then the extension should be bundled with the plugin; otherwise, it should be optional but promoted via something in the Dashboard, in the documentation, or elsewhere.

Anyway, so not everything is as black and white as simply relegating things to a theme or a plugin. Sometimes we need to write theme-specific code that needs to be organized into modules that aren’t literally files like functions.php and other similar files.

The notion of theme extensions give us the ability to do exactly that while still giving us options on how we distribute the functionality with our themes.


Join the conversation! 2 Comments

  1. To me, extension is just another word for theme-related plugin, but it’s still just a plugin (or it’s just functionality built into the theme), so I think using another word for it is just stretching for legitimacy in making this decision to attach functionality to a theme.

    In any case, the one question that needs to always be asked before making this kind of decision is, “What happens when the user decides it’s time to use a different theme? Will her data disappear or will the site be unable to function?” If so, then that’s a lock-in, and at best, the user needs to be made very aware that they are essentially signing on to this theme for life.

  2. You say, “If the functionality is required, then the extension should be bundled with the plugin; ” but I would ask, “does the extension require the theme?” Sure it is highly niched to that theme but as an extension can it be in the “mu-plugin” folder then? It’s functionality is unique to that site the theme is just too keep up appearances ;)

    Great post!

Leave a Reply