This is probably the most unique way that I’ve started a post since I’ve been writing here, but given the fact that my family continues to grow every couple of years or so, I figure that it stands to reason that the forthcoming example would be inevitable.
This past weekend, I was doing the usual routine of unboxing, ahem, diapers, refilling the wipe container and so on.
There’s nothing spectacular or unique about what you see above, except for the fact that Huggies makes both the container and the wipes that fit within the container.
But here’s the neat thing: when you purchase the wipes made by the vendor of the container, they provide a separator to let you know exactly how many to get out to fill the container.
I hesitate to say that this is kind of “neat” because, y’know, we’re talking about diapers. Additionally, we can technically buy any wipes and/or any container just so long as the wipes stay fresh, right?
But when you purchase both of the products from the same vendor, then there’s this small bonus that you get in terms of grabbing the exact amount of wipes you need for the container. Obviously, the two were made for one another.
So, naturally, I made the leap into thinking about WordPress themes, WordPress plugins, and theme-specific plugins.
It’s what anyone would logically do, right?
Reasons for Theme-Specific Plugins
Generally speaking, one of the nicest things about WordPress is that we can change the look, feel, and presentation of our blogs and web sites through the use of themes. We can then extend or remove functionality based on the plugins that we install.
Granted, the lines are heavily blurred between presentation and functionality right now (and I personally don’t think this will ever change), but there are a number of theme shops and plugin developers who get it and who truly want to make sure they keep the two concepts separated in the work that they produce.
When you look at it this way, it looks as if we have but two options:
- Mix functionality of plugins with the presentation of themes
- Create a strict line in between themes and plugins such that presentation is truly separate from functionality.
But there is a third option that sits in the middle of the two: Theme-specific plugins. In other words, there are plugins that are designed to work only with specific themes.
This raises the question “Then why would you just not build it into the theme?” The thing is, the plugin can still be designed for a specific theme, but that doesn’t mean it has to be isolated to that specific theme.
For example, let’s say that I wanted to create a unique widget specifically for a theme on which I’m working. The plugin has specialized functionality that’s suited best for the theme, but perhaps someone else would want to introduce it into their theme.
This means that some of the code that goes into the plugin should be contained in the theme and nothing but the functionality should reside in the plugin.
Going even further, this means that we’re building all of the functionality into self-contained files, functions, classes, or whatever paradigm you opt to use, but we’re leaving the stylesheets, images, and anything that provides presentation of the plugin’s front-end in the theme.
From a software standpoint, separating the concerns of our project into modules or components is a best practice. From a WordPress standpoint, separate the functionality from the presentation is a best practice.
So am I really saying that we should be creating theme-specific plugins? Sure, why not? But I think perhaps we can better summarize it as “this plugin works best with [this] theme.”
That is to say that plugins that are designed for specific themes may need continued development specifically on the front-end when they are going to be used with other themes, but I think that there’s something to be said for creating a theme and a small market of plugins specifically around that theme that help users introduce features that they want without having to carry around the weight of things they’ll never use.