Practical WordPress Development

Isolating Styles When Creating a Theme-Specific Plugin

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.

I told you this was going to start off weird.

I told you this was going to start off weird.

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.

The divider separates how many wipes fit in the container.

The divider separates how many wipes fit in 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.


  1. Nate Wright

    I think you’ve hit on an aspect of the themes vs. plugins concern that needs more discussion in the WordPress community. I understand that “frontend” is typically a theme’s territory. But I’m not convinced that it’s a good idea to have a plugin whose frontend components are only compatible with a theme that has been designed for it. (I’m sure there are examples you could come up with where I’d agree, though.)

    I raised this issue before with Justin Tadlock’s theme-oriented restaurants plugin and he has some interesting things to say about it. I disagree with his position, but it’s worth reading in full.

    Justin’s argument hinges on his opinion that plugins can’t reasonably integrate front-end components with all the diverse themes out there in a very nice way. He’s absolutely right. But in my opinion the enduring strength of WordPress is the vast mix-and-match ecosystem which allows people with very little knowledge to bolt on extra features and components to their site as they grow and adapt. Many of these people will never have the skills to create a frontend component for an existing plugin. Maybe they can write a CSS rule or two, but that’s it.

    Does this represent an ideal website development method? No. Are these components likely to look “tacked on” rather than professionally integrated? Definitely. But I’d wager that this represents the manner in which a large majority of the WordPress websites out there have been created. This haphazard approach is an important part of the platform’s on-boarding process. And though it may seem like heresy to many designers out there, I’d also say that for the kinds of small businesses that are often doing this, the content is more important than high-quality presentation.

    By refusing to build any fallback presentation layer into your plugin, I think you’re effectively reproducing the theme lock-in that the functionality-in-plugins rule was designed to avoid. Yes, someone with knowledge can retrieve that data and build a new presentation layer for it. But that still represents a large hurdle.

    I think a better approach is to build in basic frontend fallbacks and add hooks to override the output. Then themes can hook in to to dequeue stylesheets and prevent unwanted HTML output from being written to the buffer. With well-conceived hooks, they can generate their own output without adding much bloat to the plugin or the theme. But if a user switches themes, they’ll at least still have working content.

  2. Ulrich

    This discussion is always interesting.

    I know that there are some plugins on the repository that only work with paid themes. On one side it is frustrating for users as you cannot use them as you are not using that theme but on the other hand it makes it easier to distribute.

    CyberChimps created a plugin as a themes had functionality that was not allowed to exist in the theme. We made it that it would work with every theme. This only worked as we used WordPress filters. It is not everywhere possible as not every theme has the same hooks but the plugin could always show users where to hook into.

    Note makes a good point too with the default layout and styles. Pippin made a good point once about separating the structure styles and design styles.

  3. Mickey Kay

    Agreed. Another way we like to look at it is creating plugin-specific styles in our themes. What’s working well for us these days is implementing the TGM plugin activation class in our themes, and then creating the styles for those specific plugins. I would love to see more themes moving toward this model of utilizing generic plugins and applying specific styles within the theme.

  4. Chris Howard

    Tom,not sure if this entirely addresses your article, but this my experience based on predominantly writing theme-dependent plugins.

    I’ve made very good money out of my theme-specific plugins over the last three or so years.

    Initially, I think that is the biggest advantage. You have a smaller market, but it is much more easily targetable, enabling you to quickly leverage up an income. Thesis, Headway, WooThemes, Genesis all provide that opportunity. Eventually though, you will reach a plateau, as even the big themes still only have 100s of thousands of users compared to WP’s 10s of millions.

    But it comes at a price. Dependency. Not only can WP changes break your plugin, but now theme changes can too. It can me maddeningly frustrating! You may also have to adhere to that theme’s policies if you want to work closely with them.

    Every day I’m trying to keep maximum compatibility with WP, and, importantly, several popular plugins such as WooCommerce, NextGen Gallery, Gravity Forms and WPML.

    If I can remove one dependency, especially if it’s the theme, then that provides me many advantages such as enabling tighter adherence to WP coding practices, independent code that is more easily re-usable, a wider market and greater independence to choose my own direction.

    I am moving to theme-independence. But, that said, the code is not entirely generic. I still aim to be compatible with WP’s own themes (T14 etc) and I still may build specific modules to add particular theme compatibility – but not dependency. E.g. My base will always be WP’s CSS elements and classes (though every theme should be doing that too…)

    I will still maintain some of my theme-dependent plugins, but most I will be making theme-independent.

    The biggest hassle I see in going independent is marketing. It seems to be DIY (with EDD, SellWire, FetchApp etc and maybe a Lite version on WP plugins) or an established marketplace, like Envato – whose pricing structures I consider quite unfair.

    It seems to be the frying pan or the fire! But, all up, I find it disconcerting having all my eggs in one basket. Maybe I’m a control freak. :/

    • Tom

      This was a really good read and I appreciate you sharing it.

      In terms of a being a control freak, I don’t think so – after all, I was going to take this one step further and only do theme-specific plugins for my own themes :).

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑