“Requiring” Plugins

I’ve started working on a redesign of this site (spoiler alert: it’ll be responsive! Eventually.), and one thing that’s kind of dogged theme developers (I think) is what to do about plugins that are pretty much required in order to make your theme go.

To this point, it hasn’t been an issue for me. Pretty much every theme I’ve developed has been unique for a particular client, and I have as yet attempt to release a theme to the WordPress theme repository. Ergo, if I required a plugin for the project, I installed it. Boom, done. However, in creating a theme for the general masses, I could totally see me needing to include something like a plugin that lets you add classes to widgets and that sort of thing.

So the question becomes, how best to go about this? I see three possible solutions:

“Include” the Plugin

For the redesign of this site, I’ve taken the plugin Custom Widget Classes, put it inside a “plugins” directory in my theme’s directory, and did the whole PHP require thing in my functions.php file. Of course, I give attribution in the source code. Besides, the whole plugin is there, meta data, licensing and all.

However, this approach has a couple of drawbacks: First, if the plugin is poorly written (and I’m not saying this is necessarily true of Custom Widget Classes; I’m just saying, generally speaking), it might not take too kindly to being moved out of /wp-contents/plugins/. I was working on a site for the client the other day where I had to rename a plugin, including the name of its directory, and because it had that directory name hard coded in lots of places, it was a pain to have to go in and fix. Another drawback is you’ll have to go into the plugin code and make sure that all of the functions it declares are wrapped in if ( ! function_exists() ) { } structures, to protect against the person installing the theme already having the same plugin installed. Again, this is something that the plugin developer should do, but, well, you know.

So while I like this approach, it might not be the best way to go. Heck, while it might be technically allowed to redistribute a plugin in this way, is it something that’s frowned upon or not? I just don’t know.

Inform the Downloader of the Required Plugins

This means shifting the responsibility of installing plugins to the user, which I don’t like because, as someone once said, “Don’t make me think.” On the other hand, it gives them the control whether to ignore you or not, so long as they understand the risks of not installing the “mandatory” plugins. Of course, they won’t read your instructions and/or warnings, so they won’t understand said risks, and start complaining left and right on the support forums how your theme is a piece of shit. This is probably my least favorite option.

Bake In the Desired Functionality Yourself

This is very, very much like the first option, except it’s more like reinventing the wheel. One of the reasons that WordPress thrives as it does is its rich ecosystem of third-party themes and plugins that do pretty much anything you can think of. Why repeat this hard work that’s already been done? Besides, in reality, it’s going to be a lot like the first option in that you will likely have to copy and paste someone else’s code into your work. From what I understand about the GPLv2, I think this is allowed? (I’m not totally sure, I prefer the WTFPL myself.) In any case, you do have the advantage that by namespacing the functionality, you’re less likely to run into conflicts with having the “same” plugins already active. But for the theme developer, it seems like a whole lot of extra work.

Bonus Option: Don’t Require Anything

I’m not sure that this is a realistic answer. After all, there are a lot of plugins out there meant to enhance the presentation experience (the aforementioned widget class plugins, for example). If your theme wants to leverage this kind of additional control, it needs to be included in some manner. Not including it and settling for a theme that is less capable seems like short-changing the potential users.


Someone, somewhere, way smarter than me has probably already figured out the best solution to this. If so, I’d love to know what that is. Or am I right in this being an unresolved issue in the community? Please let me know your thoughts in the comments. Thanks!

7 thoughts on ““Requiring” Plugins

  1. So Jon Bishop (@JonDBishop) voted through Twitter that he’d most likely go with the second option, so long as the theme was usable without the plugins. So insert option 2.1: Having a list of “recommended” plugins on a theme options page. He also noted that requiring plugins that you’re not the author of is dangerous, and this kinda goes along to my problems with option number 1.

  2. If you’re making a theme for a client, I’d say option 2 is the best (well, option 4, fork the plugin and recommend THAT instead).

    If you’re making a theme for the masses, though, make sure the theme works without the plugin. Requiring a plugin for a theme to ‘work’ is one of those things I feel is best handled by phrasing it the other way. For example. “This theme is for BuddyPress installs.” Now it works perfectly well without BP, but you have all this extra stuff. As soon as BP is there, boom. Magic. And that’s how it should be. Have the theme work sans plugin, have the cool stuff when the plugin is there.

    I tell people “Themes are to make my site look pretty, Plugins are to make it do cool things.” Yeah, there’s cross over, but when I’m writing anything, that’s how I think of it.

  3. Whenever I’ve done things like this, I’ve normally done with the second option and I do it for my clients myself.

    This way, whenever a plugin is updated, they’ll be able to update it themselves. Plus, you should be able to code defensively in your theme to check for the presence of the plugin or not. If it’s inactive, then you can hide certain functionality.

    To Mika’s point, whenever I have bundled a plugin with an existing theme, I make sure that there’s a strong case to do so – namely, that there’s some customization to an existing plugin (either one of my own or someone else’s) that is unique to the implementation.

    I then give the plugin a slightly different name (usually by appending the name of the site to the plugin’s title in the README and in the plugin’s header file) so that it indicates this is not the usual plugin and that it’s a variation thereof.

    As a rule of thumb, don’t bake a raw, unedited plugin into a theme.

    Hope this helps :).

  4. My view is that “Inform the Downloader of the Required Plugins” is nearly always the most reasonable and responsible option. When I heard people say that asking a user to install a plugin is just too much for the user, I assume they’re just guessing. I’ve had thousands of users install Options Framework with no questions whatsoever. Anybody can follow a notice that says “Please install this. Click.”

    The theme should also work fine without the plugin, albeit in a limited way. The user won’t wonder where all the cool features are because they’ll recall that message in the dashboard that said, “Please install this plugin for the cool features. Click.”

  5. This is a very difficult dilemma to find a good solution to, and as you have noted several possibilities above I would agree with each depending on the circumstances and the ultimate end-user(s) of the theme.

    Although, for the most part, I look at the last option “Bake In the Desired Functionality Yourself” as in most cases if the “plugin” is really needed then it represents no extra work whatsoever, it simply represents required work. The use of an existing plugin (or snippet for that matter) and its functionality within the theme still falls squarely on the shoulders of the theme author.

    Also, as both a theme author and plugin author, I see the inclusion of a plugin with a theme completely the responsibility of the theme author and the upkeep of the plugin code and how it interacts with the theme falls, again, squarely to the theme author … and if that is the case then why not simply “bake it in”?

Leave a Reply

Your email address will not be published. Required fields are marked *