One multi-task plugin vs. several single-task plugins?

Recently, I’ve been giving a lot of thought to the debate over whether it’s better to develop larger plugins that handle many related tasks or smaller, mini-plugins that handle extremely specific tasks. There’s merit to both arguments, but I wanted to give my readers a chance to discuss this and help me come to a decision about how I developer some of my future plugins.

The biggest reason for this article is that I’ve been trying to make a final decision on how one (or multiple as the case may be) of my plugins will be developed. Other plugin developers might also find this discussion useful in helping them make decisions.

The example plugin

I want you to have an example of what I’m asking you to discuss, so I’ll give you a few details on the plugin(s) I’m developing. It is a set of extensions to how comments are handled in WordPress. Some of these extensions include:

The plugin currently has several options like the above. Basically, it’s just an extension to the “Discussion Settings” page in the WordPress admin. It’s easy to see how some users might only want to use one or two of those settings rather than all of them.

Advantages of a single, multi-task plugin

The following is a list of some of the advantages to running a single plugin:

You only have to run one plugin. Many people live in fear of running “too many plugins” because it might somehow break their site. Realistically, running too many large or poorly-coded plugins would be more of a problem. While you can’t really have too many plugins, this fear from users is something to consider.

Fewer things to manage. No one likes to update plugins every day. The more plugins you have, the more likely you’ll have to update them frequently. Having to only update a single plugin instead of several is easier.

Fewer translation files. Translators would only have to update and maintain a single translation file for one plugin as opposed to multiple translations for multiple plugins.

Advantages of multiple, single-task plugins

The list below is some of the advantages of using several plugins.

You don’t have to load code you don’t need. Using mini plugins means that you only have to load and run code that you absolutely want. With a single plugin, there may be several parts of the plugin that you don’t want to use.

There’s generally fewer bugs. Less code in a plugin means there’s less chance of bugs arising. It also makes it easier to find and fix bugs more quickly. Thus, allowing plugin developers to quickly get out new releases when they’re needed.

Fewer database options. With multiple plugins, sometimes you don’t need an option at all. The plugin simply works. With a single, large plugin, each setting might need to be enabled/disabled.

What are your thoughts?

Think about the example plugin I mentioned early in the post. If I allowed you to make the final decision on whether you’d like to see this developed as a single plugin or multiple plugins, which would you choose?

Now, think about the plugins you currently have installed on your site. Are there some that you’d like to see broken down into smaller plugins that only handled specific tasks?

95 Responses

You don’t have to load code you don’t need. Using mini plugins means that you only have to load and run code that you absolutely want. With a single plugin, there may be several parts of the plugin that you don’t want to use.

Could you not just build the plugin to make the extra features optional? I.E.

Your setting page could have radials to activate/deactivate features that the user wants to use or doesn’t.
If features are switched off the the code won’t be called, and settings for unwanted features would not load on the plugins settings page.

Yes, you could do that. Some code must run like your database settings whether a feature is active/inactive, and you could split each feature into individual files and only load them if a feature is activated.

However, this may be slower in terms of load times itself. You’d have to check the database settings, then load multiple files based on the settings. I’d love to see some unit tests on something like this.

Back to the question at hand: Would you rather see multiple mini plugins or a single large plugin?

Supposing that the plugins didn’t have complete settings pages, would you choose differently? I’m not a fan of settings pages unless absolutely necessary. Typically, single-task plugins don’t need settings at all. They simply perform their task without the need to activate any settings.

Not really, because if I happened to want to actually use all of the features, that would be four or five plugins added to my plugin page, again, I considder that, clutter, you could call me OCD about it.
I’d still rather one than many.

I have developed (for internal use) one larger, multi-purpose, plugin that I can enable and or disable via the plugin settings panel.

Instead of writing and storing yet another value in the database which describes which features are active and which are not, I instead write to file, which upon the initialization of my plugin will load components based upon the value encountered in a conditional statement.

I’ve done no unit testing to date, but I certainly don’t see any performance decrease and not having to hit the database with a query is a plus.

I totally agree with you, as in in my experience I was forced to use multi functionality plugins which caused my website load a lot of slower and I am talking not only wordpress cms.
Now I am using only targeted plugins or trying to develop similar functionality by myself.

I prefer third-way which is applicable to some plugins like Gravity Forms, Wp-e-commerce. These plugins defines hooks, using which smaller add-on plugins can extend the main plugin.

This way, the big plugin provides core/important features but at the same time keep provision for other uncommon features.

As an example, say I am switching to Gravity Forms from say Wufoo. Now having Wufoo importer in “Gravity Forms” will make
-(a) “Gravity Forms” big which is like degrading plugin for non-wufoo users.
-(b) Old Wufoo users will also live with unnecessary codes which they might need only once (at the time of switching).

So such functionality should be provided as add-on plugin. Use once and then remove!

Yes, some plugins don’t perfectly fit into this scenario. I have a couple that work the same way. I love plugins that add hooks to allow other plugins that extend them.

However, let’s look at Gravity Forms as an example. This is one of my all-time favorite plugins, but I think it could easily be broken apart into several more plugins. You could strip away some of the unneeded parts into plugins for only users who want them. For example, on the “New Form” screen, there’s several meta boxes for different types of fields. You could easily split off the “Advanced Fields,” “Post Fields,” and “Pricing Fields” meta boxes that come with a default install of Gravity Forms into add-on plugins. The latter two are things I definitely don’t need on most installs.

I feel same about Gravity Forms. May be Gravity Form team has some non-technical reason to include some “not-so-common” features in core.

Off-topic – when you take this approach, IMHO, its core plugin developers responsibly to provide a listing of third-party add-on plugins. Otherwise a lot of add-on small plugins may go unnoticed.
GravityForms themselves do not publish any such list where-as a simple Google search shows more than 20 add-on plugins are developed for Gravity Forms in community.

I think a good comparison to this is how Otto handled the SFC plugin. Originally, it had a core plugin, and then numerous other plugins you could activate if you wanted. I found that difficult to manage.

Now, it’s simply a matter of enabling the options you want to use. Much easier.

I came here to say the same thing. I really like the approach Otto took for the Facebook plugin now, as opposed as the prior approach (the one he still uses in the Twitter plugin).

My favorite approach is having a big plugin but load classes conditionally to the user selected options. Yes, you’ll have some overhead. You combine much of the advantages of both options you described, and also

1) I don’t think that the overhead is bigger that what takes WordPress activate several smaller plugins.
2) The usability for the end user is much better.
3) You can have shared libraries and functions.

And about “There’s generally fewer bugs. Less code in a plugin means there’s less chance of bugs arising.”, that sentence of course is true. But I don’t think its really applicable here, because for the same set of features your codebase will be in fact bigger having it separated in a bunch of small plugins.

1) It’d depend on the plugin.
2) Which end user? Those who want all the features? Or, those who just want a single feature?
3) For some plugins, yes, that makes sense.

My codebase would not be bigger if developing smaller plugins. It’d be much smaller simply because most of the smaller plugins wouldn’t need options. It’d simply run, no different than dropping a few lines of code within a theme’s functions.php file.

No, it would not be at least the same. There would literally be less code with the multiple-plugin approach. Obviously, this would change from plugin to plugin, but speaking about my example plugin, there’d simply be fewer characters of code.

Nevertheless, none of this really matters too much from an end user’s perspective.

Anyway, for the end user (for me as end user, at least) is easier to download/upgrade one pack and activate the functionalities I want, providing the set of functionalities have a clear goal in common. (ie: Don’t like the JetPack approach, but I do really like the change Otto made)

Didn’t know SFC has been changed! I stopped using Otto’s plugin because of “multiple plugin” approach. There were too many plugins on my screen to manage!
Thanks for update. Will definitely give SFC another look now.

Another thing to consider is the developer. It’s easier to maintain a single plugin with one repository, one channel of advertising, and no need to duplicate anything. A security flaw may exist in every smaller plugin that was released and now they all have to be updated, tested, committed, new changelog, blog posts, etc.

Over time new features will be added and then the decision has to be made whether the feature merits merging with an existing plugin or creating a new plugin.

As it pertains to this example plugin, comment customization, most people’s goal installing a plugin like this would be the same: stop spam. Except for the enabling/disabling comments per post type, the features relate to spam so they make sense to bundle together. If users are inclined to use 51% or more of all the singular feature plugins then they probably merit being in 1 plugin.

Great feedback, Patrick. I can definitely agree that it’s easier to maintain a single plugin in a repository as opposed to several.

I’m not sure how a security flaw would be in each of the smaller plugins since they’d be completely different with different code. Security issues would be limited to individual plugins and easier to find/fix.

Each of the smaller plugins should not need new features over time. If the plugin was a single-task plugin (as I’m proposing), it’d most likely never have to be updated except for changes in WordPress or if a bug was found.

Instead of a security flaw instead relate it to a new WordPress version where comments were overhauled and a new function would be best used throughout every plugin. The same update would need to be made to all plugins. Similar to a security flaw in that if you incorrectly used a function throughout all (the wrong escaping filter, for example) then they’d all need to be updated.

It’s rare that WordPress forces an update on plugins. It has a proven track-record with backward compatibility, but it’s definitely a possibility that a new function or hook might make you update several plugins.

I don’t see that happening in the case of the plugin example I gave since each single-task plugin would use different functions and different hooks (except for a couple). That’d have to be a pretty hefty overhaul of the comments system with no regards to backward compatibility.

SFC by Otto which is a great example of this is about 508kb, Jetpack on the other hand is 3.5MB of which 2mb are language files, both provide a way better end user experience that a “ton” of small plugins.

Won’t adding massive to it taint the response, no one really likes a Massive anything, I would prefer one well optimized plugin.

In my opinion I would only split things up in separate plugins only if the split feature on it’s own is useful enough to exist on it’s own.

I see a benefit in writing bigger plugins given that your code design is done right and you can reuse a lot of your code which you would otherwise need to duplicate in each of the smaller instances. But this is only valid if the code is well structured, secure and scalable.

If you’re a beginner you’ll likely be better off just writing smaller plugins.

I like what Thorsten Ott said, “I see a benefit in writing bigger plugins given that your code design is done right . . .”

I feel that developers have gone mad with creating plugins. I would rather see larger plugin with multi functionality then use 10 small plugins instead.

My biggest beef and concern is the ongoing development of what I call quick coded plugins, like what you find on the WSO Warrior Forum. People are buying these plugins on dime sales or for $9 – $15 but when you look at the code, its just plain dirty most of the time.

I feel I would rather see good developers create great plugins using clean code and offer multi functionality, which would in the long run prevent a lot of the conflict you are seeing with many of these “quickie” plugins.

I would also prefer to see a team of plugin developers work together on a plugin platform standard where each of their plugins would be compatible with fitting into a larger plugin using hooks for example.

I prefer multiple mini plugins. I can choose the mini plugin that best suits my purpose. A large plugin might not do justice to all its abilities.
For example the Yoast SEO plugin is not very good at xml sitemaps. I prefer to turn that feature off and instead use the Google XML Sitemaps plugin.

I prefer several mini plugins. As developer I like code that I can easily read and understand all the plugins do. I just use a big plugin when I have no options or it is very well accepted/recognized by the community.

When you have mini-plugins you won’t need so many updates on code or translations. It will become stable easily and breaking things is harder.

I also think that mini plugins is easier to fork and learn from.

Wordpress is extensible using hooks, so I appreciate when a plugin is simple and are extensible by hooks, like Wordpress is. If no admin settings, better!

I prefer one plugin as long as the the features are somewhat closely related.

I like how you have Members setup so that you can choose what functionality you want to activate. I think this is a good approach for small and medium plugins, and if it gets large enough, add-on plugins can be used instead, similar Gravity Forms.

Speaking of, I’ve got a few add-on ideas for Members. It was really built to be extended. But, yeah, I like how it’s done as a user of my plugin as well. It can be nice to have all of that functionality within one plugin as long as the plugin doesn’t grow too large, which is is something I try to be careful to avoid.

I do this often with my Members plugin too, mostly with client work. They might need feature X or Y for their site, so I’ll just extend Members to handle it. I’m a big fan of medium-large plugins that are easily extended, especially if they’re creating a framework of sorts.

This is a really good discussion and something that all WordPress developers have pondered over from time to time.

My stance with plugins is two-fold. They should only load code that is actually needed and they should provide as few options as necessary (preferably none). Too many options becomes too confusing to the user.

Therefore I guess that I am leaning more to the lots of small plugins option! However if the functionality is closely related or connected to each other then maybe it would work with a larger plugin.

We prefer the small single tasks plugins in our websites. Think of the case of a Wordpress core update that messes some things up. If you have a single plugin, you will have to solve the issue asap or have lots of functionality disabled.

For me the deciding factor would be whether most users (50%+) would install all of the features/mini-plugins. If so, you should probably group them together. If not, then keep them separate.

Another reference plugin is Theme My Login. They have “modules” you need to enable to activate advanced features. The plugin author (Jeff Farthing) actually turned his Theme My Profile plugin into a module for Theme My Login. I like how it works.

For my own plugin Paid Memberships Pro, I have to think about this all the time… whether a new feature is added to the core plugin, added as its own plugin (dependent on PMPro), or just added as some code in functions.php. If the feature will have UI overhead or performance overhead, I consider what % of my user base will be using that feature and if it would work better on its own.

As a fan of frameworks, I’d agree with the comment of Gravity above – building a hookable plugin that you can extend itself. So build a stable core that can handle submodules for different features. This way users can select small portions of code to add to the core and every user can build a powerful engine or use a small but light version of the same mechanism.

The other option is again larger codebase with options to load or disable some functions. Disabled functions won’t be included at all so no additional code would be loaded by WordPress at the end. There are going to be 2 or 3 checks for that but since the file is not included itself, I think it is a matter of few milliseconds only.

The only problem with the latter solution is if you have a plugin doing let’s say 10 things and you need only one of them. Normally I would look for the simplest snippet as faster, more reliable and easier to maintain.

As a user, have to throw my support behind a single plugin. Otto’s SFC has been mentioned already but I can’t tell you how relieved I was when he decided to move it all into a single plugin.

It ended up not being a plugin I could recommend to clients simply because of how complicated it seemed on install. All these new plugins appeared on their plugins page. Which one do they activate first? I want the Like button but wait, now it’s telling me it needs something else to load first? What’s the Base plugin? Activate that, then the Like button, then I STILL have to go to a settings page to configure it. I could imagine the support requests.

Compare that to now where I activate a single plugin, go to the settings page and seeing a Like button checkbox. Don’t need all of that other stuff, so no other settings show. Click the Like checkbox and configure and I’m done. Now I just have to teach them how to configure Facebook.

You might think that yours is going to be different with no settings pages, but what if they become popular and grow? Now you’re adding more features, new settings pages for each plugin and it’s just becoming less and less manageable for the end user. What, I have to go to different settings pages for each plugin (I’m sure you’d leverage the Settings API to prevent that happening, but many developers wouldn’t).

Also, what if all plugin developers did this? Imagine the plugins being 10 pages long. How frustrating to have to hunt down or search for an installed plugin in that huge long list of one-plugin-per-feature plugins instead of now where 15 plugins fit on a page and it’s easy to scroll and find the one you need. Less page loads (not searching or clicking through pagination), quicker to accomplish the task, better for the user.

I work in a community where people just want to write and publish photos. They’re not developers. WordPress already seems too complicated for them. They (quite rightly) couldn’t care less about how much less code you had to write or that it’s 200ms slower to load. Make it easy to use.

Thanks for your thoughts. Getting opinions of users is what I’m after.

It ended up not being a plugin I could recommend to clients simply because of how complicated it seemed on install. All these new plugins appeared on their plugins page. Which one do they activate first? I want the Like button but wait, now it’s telling me it needs something else to load first? What’s the Base plugin? Activate that, then the Like button, then I STILL have to go to a settings page to configure it. I could imagine the support requests.

That’s a bit of a different scenario than what I’m describing. Similar but different. Those plugins are dependent on each other. Rather, I’m just referring to independent plugins.

You might think that yours is going to be different with no settings pages, but what if they become popular and grow? Now you’re adding more features, new settings pages for each plugin and it’s just becoming less and less manageable for the end user.

I haven’t decided on what I’ll do with mine. I’m open to either route. But, the single-task plugins don’t have room for growth. They simply do a single job and can never do more.

Great topic! As things stand, as a user I’d probably opt for the all-in-one plugin.

That said, I think this is a problem that would be best solved by WordPress itself. As long as there’s no shared codebase or dependencies (as was the case with Otto’s SFC), splitting up functionality into several smaller plugins seems like an all-around clever thing to do — no single point of failure and all that jazz. WordPress should accommodate this design decision. What if plugins could come with their own ‘Type’ tags?

Type

Looking at WordPress’ API, with all its hooks and primary functions, it shouldn’t be that hard to determine what core pieces of functionality there are. Pick out the most prevalent terms, and there’s your most common types of core functionality in WordPress extended by plugins.

So if there was such a thing as Types, all you’d have to do for your collection of comments-centric plugins would be to tag each one of them with ‘Comment’, and WordPress admins wouldn’t easily lose sight of their plethora of plugins installed to add tid-bits of extra functionality.

So that’s my big “what if”, he he. Maybe I’ll put it up on WordPress Ideas.

Actually, this shouldn’t be that hard to do. Plugins already have “tags”. Adding a filter on the plugins screen in the admin is a possibility. We really just need to have the tags as part of the plugin header instead of the plugin’s readme header.

I’d like to see more limitations on the tags that can be used though just like with the theme repository. I hate having to search through both the “admin” and “administration” tags for plugins, for example.

It’s almost certain that any given collection of mini-plugins you choose will not have been tested with each other so I’d say the more plugins you have the more bug you have, not less.

I can see the logic in that, especially when dealing with multiple plugin developers. I’d argue though that bugs are more easily found and fixed when you have smaller code base. Of course, better lines of communication for plugin dev on .ORG would help in that regard.

Lastly, if a mini-plugin can exist and needs zero admin options, I’d ask why isn’t this capability built into core, at least that can be easily switched on/off? But on this I digress…

Decisions, not options — that’s the answer you’d get from the core devs. There are 1,000s of things that could be done with single-task plugins to change something in how core works. I’ve written hundreds of them in client work over the last few years. I don’t see it as a realistic option to add settings for these things into core.

To me the “Decisions, not options” mantra, like any good rule of thumb has become a lot more like dogma among the core WordPress community then good sense. And like any dogma it is often applied religiously without consideration for circumstances. The whole “Themes should have no options” meme is a good example of that mantra taken to its dogmatic extreme.

But I know I’m in the minority on this issue among visible WordPress developers in the core community and that okay. So my work will tend towards “Options, not code”(or if I allow myself to be crass, “Functionality, not pedantry” .

But seriously, when I refer to “options” I mean switches that a site builder can set vs. having thousands of checkboxes for the end-user to set. And I’m pretty sure there is a large segment of professional site builders who think the same way. So we’ll see if I’m right or wrong later this year after we release Sunrise to open beta.

I am a user that is finding this a very interesting discussion. I have been concerned about overhead when using “large plugins” when I only need few of the functions.

For example, I have a short code plugin that has over “100 built in styles” to use in the WP editor – I only need three of the options. As a user, I worry about if loading in all those styles will effect my site performance (this may or may not be true – I’m not a plugin developer so I don’t know). I have opted for three plugins to do the simple tasks I need, because of this concern. If I could “turn on” only the options I need I would probably use the large plugin.

A point well taken in this discussion is that “large plugins” can help the users like me avoid the problems of compatibility issues that often arise when using a collection of mini plugins. I’ll be following the discussion to learn more.

as fyi, when i read your post i was reminded of a conversation over drinks i once had with an assembly language programmer, Ethan Winer, about why and how Ethan’s BASIC tools were superior to the then MSoft tools and others on the market back in the day …

apparently, MSoft thru in the kitchen sink with their code thus had all routines and was complete but Ethan’s approach was different …

and while during our conversation he did not use the terms hooks and functions, he did mention that his code would run just the minimal amount needed to get the job done, and when done, closed …

thus his solution, which you can read a bit at this link -> http://www.ethanwiner.com/p_pdq.htm -> put him on the MS DOS map with other developers as a leading supplier of robust tools vs the default tools shipped from Seattle thugs …

it also made him a millionaire (the first time around as Ethan is a serial entrepreneur and is currently at http://realtraps.com) …

and perhaps most interesting, before Open Source was even known and respected as it is today, even back then Ethan was enlightened enough to sell his tools with FULL source code and documentation – something that many at the time thought incredulous – although most of those folks were the same reptilian cold-blooded coders who bought into the MSoft kool aid approach of divide and obfuscate but i digress …

accordingly, my vote would be for smaller, faster plugins on as-need basis as i’ll take superior performance over convenience anyday …

best of ongoing success with your plugin development … cordially, chuck scott

If there’s one thing I’m annoyed with, it’s all that extra stuff that cannot be turned off, which usually happens with massive plugins. Then I have to disable scripts and stylesheets, write notes to myself and, in case of the most famous gallery plugin around, each time it’s updated, I have to look for one same file to change memory limit in it, otherwise the whole site is inaccessible.

So, IMHO, massive plugins should come in beginner, intermediate and advanced mode. Or at least the first and the last of those three. And definitely no pre-defined colours or anything hard-coded, with a clear clue on how to remove the styles (so one doesn’t have to google around).

I have given this same situation a considerable amount of thought with CodeIgniter libraries that I’ve written. I always break things up into smaller libraries when possible. I think this makes the code much easier to maintain.

With how easy it is to add/remove plugins in WordPress, I’d think it would be best to break things apart since it’s not really an inconvenience for the end user to install multiple plugins. As a fellow developer, I would say make your life a little easier and break things up

I see several limitations of the current plugin architecture which means lots of mini plugins aren’t the best solution… for now:

1. There is no proper dependency management system for plugins. This means if I want to install a mini plugin, which needs an existing plugin for it to function, there is no way to validate this, or have it auto install the dependencies. (I know you can check if a class or function is defined, or if a folder exists within the plugin directory, and infer if a plugin exist, but this is not ideal). Dependencies could be added as meta data in the plugin header.
2. The plugin screen would become a mess. An easy way to resolve this would be to group plugins, and have sections based on functionality, for example, a section for all “Discussion” related plugins. The section a plugin is placed in could be added using another tag in the plugin header.
3. A diverse developer base, could mean that lots of mini plugins co-exist and work together, but there is nothing to stop one of those causing an issue to the others. If there was a single plugin developer maintaining one large plugin, it would all be tested together (the same is true for a good developer releasing lots of mini plugins to co-exist).

As a developer, the idea of mini plugins, which do one thing, and do it really well, appeals to me, and if people think there is demand, I’d be happy to help contribute and try to resolve some of the issues listed above.

I believe there is a huge demand for quick, single-task plugins in the WordPress community. Folks just don’t know it yet. The reason I’ve come to this conclusion is that I can clearly see that there’s a demand for quick code snippets. People love just copying a few lines of code and dropping it into their functions.php files. While there’s nothing wrong with doing that, it’d be much easier to simply click a few buttons and have the code instantly installed.

1) That’s a bit outside the scope of the proposed discussion but definitely worth discussing. Dependent plugins aren’t exactly the same thing as single-task plugins. Single-task plugins would have no dependencies on other plugins. I’d love to see some sort of dependency mechanism built into WordPress core though.

2) I proposed earlier that we use the current tags system for something like this. I’ll probably be writing something more in-depth on this soon.

3) There’s nothing to stop any sort of plugins from causing an issue with plugins, whether they’re small or large plugins. The best thing we can hope to do is to better educate plugin developers on the use of proper hooks, functions, and coding standards.

My preference as an end user is when I’m managing a site I only want to have the functionality I need and not be shown stuff I don’t want. For example, if you had a plugin that ‘Automatically deletes spam on a schedule’, I wouldn’t want that to activate loads of other features in the UI.

If a single plugin adds multiple features, those features should be very closely related or integrated with each other. Ideally if there are extra options for each bit of functionality they should be added to the appropriate settings page if possible rather than adding lots of new settings pages.

As a developer, I would manage this either as mini plugins, or as one larger plugin with modules you can activate in settings – providing the functionality is all closely related (ie Members plugin). If the plugin provides an extensive amount of functionality then a core plugin with add-on plugin modules would be better (ie Gravity Forms).

Where possible I prefer to build smaller plugins with hooks where necessary rather than a package of functionality as I find them easier to debug and update. I only usually consider the package or add-on approach if the functionality of the plugins could be inter-linked or there is a strong likelihood that a user may want to use all the functionality at the same time.

Hello Justin, you got an interesting point to discuss about! Well , In my point of view the multi task plugins as well as the single task mini plugin both have their pros and cons. The multitask plugin indeed, would be easy to manage and get the work done but it may not run and process much faster as we know that the multi task plugins would need more processes to carry out for completing any task where as the mini plugins would work much faster. The mini plugins get difficult to manage when we use a big no. of plugins. Thanks Justin!

In my opinion from a webmasters point of view it is better to have one as opposed to many but certain tasks are best managed with individual plugins – as long as the code is good and everything works as it should I think many will find that a hybrid of a main plug in and a few task specific one will normally be the usual scenario.

Single service plugins are a good idea to give admins the power to choose what features they need, as well as to stick with conventions that keep all features as closely built to the WordPress core as possible for security, performance, and interoperability purposes. However, there are times when bundling features makes sense. For example, we have a community plugin Benchmark Email Lite that we are revving, and the new 2.0 version will offer multiple features (i.e. widget and metabox). We wouldn’t want users to get confused making redundant settings or dealing with plugin dependencies. So to the extent the features compliment each other and share dependencies (i.e. Benchmark Email account credentials), a bundled plugin is better for the users. Another idea for larger plugins is to build an internal ecosystem where the plugin and activate/deactivate features within itself.

I have some mixed views. When I wrote the article WordPress Not Keeping Up it was with the thought that a lot of commonly used plugins would be better off in the WordPress core, not as a plugin. A very obvious example would be a back-up feature.

With that in mind, the average user doesn’t fully understand all the nuances of a cache plugin, and WordPress has some terrible core functions for increasing cache which leaves users and developers, alike, looking into the plugin repository.

Then we have to establish a line between usability, user preference, user needs, and functionality. To effectively do this a set of standards would need to be set for each plugin package. Unfortuanately, doing this with such a large community is very difficult. Imagine having a debate with 5 million people and hoping to win your argument.

We have fantastic plugins to limit what the end user has access to, such as the White Label plugin. We can fully utilize such tools to eliminate our end user from breaking plugins by limiting what they can access. What it doesn’t do, however, is stop the need for 15+ plugins to make a website effectively work.

I fully believe that seperating plugins from templates is important and keeps for a clean coding environment. You also know I am against too many short codes.

As a solution I would strongly advise consolodating related plugins and placing obvious plugins into the WordPress core. As developers we have to assume our clients are stupid. When we consolidate plugins we need to make sure that we provide a very clean user interface or our users will simply be flooded with too much information at once and easily get lost.

WordPress supports theme options, post options with meta data and so much more. If we use a simple approach to a user interface where a user can check mark our massive plugin functions on or off with ease then we achieve our goal.

We can use several conditionals in our functions.php such as foreach, switch case, and if/else to determine what is loaded based on what is selected.

Cool. Now we can check the “Members” on to allow more user control, turn off the “Twitter” feature, turn on “Related Posts”, etc. As each one is slected the functionality becomes available in the WP Admin in a clean, categorized user interface.

Compact, only one plugin to update, and made for usability not programmability.

Its a good read Justin,
In my view a balance approach should be adopted. When a plugin performs a group of inter-related tasks then it should be “Single Plugin” but if different group of tasks need to be performed then it should be done by mini plugins.

In the above mentioned case, I think it should be a single plugin as it is performing inter-related tasks. It irks me to install a new plugin for fairly small tasks.

Performance factor, each new plugin would create its on object or set or queries. If its a single plugin then many things can be achieved the same no of db queries.

“Dependency” factor, there are many situation when new option would be the result of previous selection e.g. If comments are ON then you can filter them.

My vote is for one bigger plugin where optional settings can be turned off and it does not load any extra code if something is not required. Having said that, if it has to perform different tasks then it has to be different plugin.

In the above mentioned case, I think it should be a single plugin as it is performing inter-related tasks.

Some of the tasks are interrelated. Others are not. If you’re arguing that they’re all interrelated because they deal with comments, then an argument should be made that any comments-related plugin ever made should be all placed into a single plugin.

But, yes, some tasks are definitely interrelated. The example I gave is a poor example for this discussion.

It irks me to install a new plugin for fairly small tasks.

Why? If a plugin that performed a small task took care of some specific functionality you needed, why would that irk you?

Performance factor, each new plugin would create its on object or set or queries. If its a single plugin then many things can be achieved the same no of db queries.

Whether additional database queries are required depends on development. Generally, single-task plugins require no additional database queries. It’s more of a plug-n-play scenario that requires less work from the user and less strain on resources.

From the user perspective, I think one big plugin is better. Easier to install, to manage, to remember (more time spent on the plugin page to activate/deactivate or setting eventual options, more page to visit).

Maybe the many plugins solution appeal more to the developer (cleaner solution, better performances), but in my opinion the priority should be given to the user experience (unless the performance loss can be detrimental to the experience itself).

When a plugin interferes with a theme, if you have a “superplugin” will be forced to disable the plugin and search the error. Instead, if you have many plugins you can go disabling one by one to find out which is the plugin that interferes with the theme.
What do you think?

I really think the single purpose simple plugin works better. Most users are looking to be able to do a single function or simple thing and with a small micro targeted plugin, you are more likely to be found. Sometimes the catch-all plugin gets bogged down and overlooked by people saying “thats too complicated” or “I don’t need all that”

The perfect answer to this question would definitely be very tough as you yourself have explained the benefits of both the ways. Personally I would go for one big plugin that could do many tasks at once !

Would you like to have a plane that could kill other aircrafts, drop bombs and sink ships or 3 different planes for these three tasks.

I apologize for my violent analogy but being a regular military blogger I couldn’t find any less violent example !

I just ran the P3 Plugin Performance Profiler on one of my sites and Jetpack was the winner as resource hog and created huge spikes in the timeline graphs by a big margin over YARPP; which is a distant second but still significantly heavier than the rest that are running.

Jetpack is a lot of code; much of which I don’t have turned on. Seems to me that individual targeted plugins to do specific tasks, as opposed to a monolithic plugin that can to everything if you want that, are the way to go. Surgical as opposed to sledge hammer. Sometimes, one size doesn’t fit all—and shouldn’t.

Jetpack has its good points but the sheer amount of code that the system must wade through appears to be a detriment.

Question is, are there alternatives that work as reliably? I see a Jetpack Lite but it only has two functions of the original.

Developer skill level is relevant if we are defining advice to developers here: Multi plugin with clever options, only loading what is required is great IF the developer really knows what they are doing …. quite a few do not. Even some well known ‘paid’ plugins with several staff have very sucky admin user interface.
For lesser experienced developers, smaller plugins that can work standalone or integrated may be better.

Also lessens the risk of integration clashes where base functionality is different but there are overlapping areas – hard sometimes to debug what is stuffing what up!

If functionality is separate and standalone, I’d be inclined to keep it separate.

ASIDE:
Re addons using plugin filters and pluggable functions, code snippets and best way to handle etc… in this discussion here http://www.wptavern.com/forum/general-wordpress/2390-securing-plugin-theme-editor.html a separate ‘plugin’ was mooted for those sorts of needs and it really got my brain going. For those ‘dumb’ users who get told – it’s 3 lines of code using one of the hooks…. it might be possible to have a site-specific snippets plugin which generates one include file with all the snippets entered…..

and…. that maybe the same plugin that ‘adds’ back the file editor functionality for ‘advanced’ users only….?

I am a beginner in Wordpress, and for me the issue is about FINDING the right combination of plugins.
I, personnally, don’t like plugins that have too many functionnalities, but I can’t find what I’m looking for among thousands of plugins. What I need most would be PACKAGES OF PLUGINS or suggestions of sets of plugins. This way:
– You quickly have your functionnality set up
– You don’t have to search by yourself among thousands of tiny plugins
– You can uninstall/replace the plugins that don’t fit
– And I don’t care maintaining many plugins because the process of updating is SO simple and easy.

I think the commenter that talked about Otto’s SFC plugin was true – there were just too many add-on plugins, but the things was you got them all (whether you wanted them all or not) with one install, and there were just there cluttering up your plugins page.

The beauty of the Gravity Forms add-ons were that you just installed the ones you wanted, and that was that. Was always a fan of good Contact Form 7 add-on plugins for the same reason (just install what you want), and the fact that the functionality was outside the main plugin never bothered me.

If I could dream of a better way, it would be some kind of way to have add-on plugins without having to install them all separately. Does it make sense that I want a way to make plugins a “child plugin” the same way a theme would be a “child theme”?

Small and focused plugins suit me better. Larger multipurpose plugins also run the risk of breaking more of your site is there is a bug or conflict (because you rely on the plugin for more things in more locations on the site).

I’m coming a bit late to the party, but will make a few observations as a user.

In general I favor *somewhat* larger plugins. I would prefer to find one good solution that provides most of the commonly requested enhancements in a given area than to have to piece together a solution on my own out of three or five or seven little micro-plugins. (Which I have to find in a haystack of 16,000 plugins, two-thirds of which are out of date or not currently supported… echoing a previous commenter.)

The key is to “right-size” the plugin: bundle closely related functions that are often requested together. That might require a bit of market research — asking people which features are most important, what capabilities they really wish WP included in core in some functional area, etc.

Features that are commonly requested together are obvious choices to combine. What’s “commonly”? It’s subjective, but I’d say it’s somewhere in the range of 33% to 50% overlap — if half (or one-third) or more of the people who want Feature A also want Feature B, save the users some trouble and bundle them. That will also ensure that related features have consistent UI and behavior, which would not be the case if the user has to cobble together micro-plugins from a variety of authors.

Features that will share a substantial number of function calls, or that can reinforce each other, also make perfect sense to combine.

Small files can increase transaction costs (more loading, checking, and hand-shaking), and often they seem to have to duplicate certain other code that has to be called by each plugin, large or small. 10 small plugins make those calls 10 times.

I’m not sure I believe that 7 little plugins will be less code than 1 bundled plugin. And I suspect the 1 bundled one will load faster than 5 or 10 little ones. Let’s suppose you have 10 functions, and as micro-plugins they’re each 1K in size. And let’s suppose that maybe the average user wants to use 5 of those 10 functions. I’d bet that a single 10K file would load faster than 5 1K files.

From the developer standpoint, if you are providing 7 enhancements all related to managing comments, do you really want to have 7 workflows for updates, 7 support forums to keep track of, 7 plugin descriptions on WP.org, 7 demos to keep updated, 7 FAQs to update, etc?

As for avoiding “options” with small plugins: users eventually want options for almost every function. If you want to be helpful, you’re going to end up offering options.

For instance, take your example of “automatically moderate all non-English comments”. That could be a “no option” plugin for an English-language website. But what about a French website? Do they want comments in English published automatically while comments in the site’s native language all have to be moderated? No — they will ask for an option to pick which language gets favored treatment. And they’d be right to ask — a plugin that allows English to get special treatment but no other languages is a very Anglo-centric approach — and it could mean that 50 plugin developers will have to write 50 “no-option” plugins that do exactly the same thing for every major language.

Some huge plugins like BuddyPress might actually benefit from being broken into a few complementary pieces, in case you don’t really need one of the major functions.

But think in terms of capabilities or applications in order to right-size — what types of problems are users trying to solve? Not just the little, proximate, technical problems-du-jour, but the “How do I want to interact with my readers?” type of problem.

The best plugins are the ones that offer a solution to a usability or functionality gap in WP core:

— “I need to be able to control who has access to my site.”
— “I’d like to have separate blog pages for different topics, with a blog entry form for each topic on the topic’s main page.”
— “I’d like drag-and-drop layout of all the standard elements of a WP page.”
— “I want fine-grained control over comments on my site.”

So, for as narrow a focus as you’re proposing — e.g. comment-management tools — I’d vote for bundling. Just don’t make a single plugin for “Everything that Everyone Has Ever Said Was Missing From WordPress”.

Thanks for hopping in the discussion. You brought up some good points.

I’m not sure I believe that 7 little plugins will be less code than 1 bundled plugin. And I suspect the 1 bundled one will load faster than 5 or 10 little ones. Let’s suppose you have 10 functions, and as micro-plugins they’re each 1K in size. And let’s suppose that maybe the average user wants to use 5 of those 10 functions. I’d bet that a single 10K file would load faster than 5 1K files.

From the developer standpoint, if you are providing 7 enhancements all related to managing comments, do you really want to have 7 workflows for updates, 7 support forums to keep track of, 7 plugin descriptions on WP.org, 7 demos to keep updated, 7 FAQs to update, etc?

See my comments at the end regarding plugin type. But, yes, as a developer, I’d want to have all those things separate. It requires far, far less updating and management to have small, single-task plugins. Typically, they never have to be updated.

As for avoiding “options” with small plugins: users eventually want options for almost every function. If you want to be helpful, you’re going to end up offering options.

That’s not necessarily correct. Users always want options when they want to change the behavior of something. Installing the plugin itself is the “option” with many single-task plugins.

The best plugins are the ones that offer a solution to a usability or functionality gap in WP core:

Well said. I agree completely.

For instance, take your example of “automatically moderate all non-English comments”…it could mean that 50 plugin developers will have to write 50 “no-option” plugins that do exactly the same thing for every major language.

See comment below. There’s not much point in picking out trivial points in the example rather than discussing the larger question.

So, for as narrow a focus as you’re proposing — e.g. comment-management tools — I’d vote for bundling. Just don’t make a single plugin for “Everything that Everyone Has Ever Said Was Missing From WordPress”.

Ad »The User«) imho several small plugins are the way to go – at least for free ones. Why? Because we, who develop free plugins, mostly never get any “thank you”, donation or else. Yes, maybe we get something if we offer a plugin for free that’s used by millions of users. And therefore my personal decision is small plugins, built upon base-functionality plugins: They’re easier to maintain, debug, etc.

I don’t even host most of my stuff at the official repo, but on GitHub (or GitHub Gist) as it’s easier for me.

Ad Files) Organization matters. It matters a lot. If you code a lot of plugins, then you already have the problem of keeping your stuff organized. Yes, you have to repeat some lines (e.g. prevent direct file access), but this is ok. It’s your standard wrapper, you don’t even notice it. And the rest of the code is easy to read. At least, you have to read and understand it when you come back to improve or extend it after some month.

The same goes for options: I don’t add any. Take it as it is and if you want something special, then use the hooks, extend a class, use the public API functions or whatever you want (and whatever you’re able to do). And yes, a well thought plugin likely never needs any options. If you still really, really need them: Pay me for that. At least, you didn’t even take the time to drop by and say “Thanks, mate!”.

Ad performance) Shure, the bundled plugin will slightly be faster. But well done array and object handling, avoiding unnecessary queries, etc. will easily overcome this drawback. Then we got caching, minifying, concatenating, etc. So: I don’t care. If a user is after those 0.1% performance increase and really needs it on his 1 mill. hits á sec. page, then hire and pay me. Period, as in this case, there’s enough money on the hand.

Ad »too many plugins«) Yes, I don’t care about cavemen. If you’re interested in urban myth, then please don’t bug me with it. Bigger plugins are just more likely to be bug prone.

Yes, updates can be buggy. What I really like is the approach for the »Simple Facebook/Twitter connect« plugin framework/series/bundles. Lots of stuff we can learn from it.

Ad Translations) If I develop a base plugin that I need to extend with smaller plugins later, then I only got one base translation file. Dependencies share the same textdomain.

Hi Justin
I like the idea of a multi task plugin but wouldn’t it be like putting all your eggs in one basket.
I am not a developer but I have used hundreds of wp plugins throught out the years
and yes your right if the codes crap they usually blow a fuse and then have to be weeded out and deleted one by one.
what I like about the multi plugin idea is that it would be very easy to update and keep an eye on
cheers Mick

Single task or Multitask, makes no difference to me as long as it get’s the job done. At the end of the day you need to ask yourself what is it that you are trying to achieve and will the plugins you select help you fulfill the objective?

The real question here is how do you tell a bad plugin from a good one? I know most people look at the star ratings and how many people have used the plugin as a good sign of a quality plugin (although popular does not always mean it is good).

This is because I use Plugin Organizer plugin, where I can activate/deactivate a plugin at will, per post or page, or globally.

So if I use a plugin action for only one page, I can globally deactivate it, and activate it only for that page.

Let’s take Jetpack, a collection of several plugins in one. Unnecessary plugin actions get loaded even if one doesn’t need them, it’s a waste.

Plugin Organizer is definitely one of the most powerful plugins in Wordpress, and I don’t know why few webmasters use it. It speeds up loading through selective plugin loading, it really lives up to its name.

I believe the end product of the plugin is more important. Some of the points that you have mentioned, I thought it is good. Moderate all non-english comments or moderate non-human comments or plugins like this is rather useful for people who uses WordPress as their site platform.

Depends entirely upon the focus of the plugin. If it’s something fairly intuitive, like comments, bundle it. If it’s something confusing like SEO or custom taxonomies, codes, etc., split it. As a user, I deinstall any plugin I can’t figure out, but if it has only one function, then I can usually figure it out even as a complete newbie. If it’s all intuitive though, I’d rather bundle it up, configure my settings for everything all at once and forget about it. As a user, that also reduces my fear of incompatible plugins.

consider two additional points that have really helped in my development life.

1. “rate of change” – if you use small plugins, it is relatively easy to manage changing them without regard to unit testing a substantial code base unless it is entirely automated (hey maybe there is a product idea).

2. “design of everyday things” – a great book and relevant to this discussion. if i am a developer looking to have a plugin that adds the post id to the table of posts, it is nearly a certainty that if you also added 3 meta boxes and put a wrapper div around the post that i would be suspicious and maybe even pissed off.

I do believe all the ideas you have presented for your post. They are very convincing and can certainly work. Still, the posts are very quick for beginners. May you please lengthen them a little from subsequent time? Thank you for the post.

By submitting a comment here you grant this site a perpetual license to reproduce your words and name/Web site in attribution.

Please use your real name or a pseudonym (i.e., pen name, alias, nom de plume) when commenting. If you add your site name, company name, or something completely random, I'll likely change it to whatever I want.