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:
- Moderate all non-Enlish comments.
- Automatically delete spam on a schedule.
- Turn on/off comments for specific post types by default (like with posts).
- Moderate all trackbacks and pingbacks.
- And more.
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?
Are there any other advantages or disadvantages you’d like to share?
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?
Personally, I’d prefer a single plugin, My issue with “loads of plugins” however is more to do with aesthetics then with loading times, I hate having my settings pages overly cluttered.
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 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.
Thanks for the feedback on a real-world plugin that made this change, Michael.
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.phpfile.Yes, that’s why I said “same set of features”. If I want all your modules, the codebase will be, at least, the same. Probably a bit bigger.
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.
I can see that for really small plugins that make sense.
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.
Shouldn’t the emphasis be placed on the end user?
For me end user experience trumps all. A well designed and optimized plugin should not have a lot of the disadvantages mentioned.
I like the idea of a single plugin, why does it have to be massive?
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.
I hate Jetpack. That’s just too much unrelated stuff in a single plugin, most of which I don’t want or need. It’s a perfect example, to me, of what should be avoided.
Otto’s plugin seems like a better example of pulling things into a single plugin.
You’re right on the use of the term “massive.” I’m updating the post.
Most dev’s do but my end users prefer it, the GUI seems less intimidating, are end users ever factored into these conversations???
This entire discussion is about end users. My response about Jetpack was as a user, not a developer. From a development perspective, I could go either way. It doesn’t really matter to me.
I’ve found that most end users I work with don’t like how Jetpack works. They don’t understand what all this other stuff is for.
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.
Great feedback. I like the idea of splitting features into their own plugins only if they’re useful enough to be a single plugin.
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.
Hope this made sense . . .
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.
Hi,
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!
So, my vote is mini-plugins++
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.
This is an interesting subject.
If given the choice I think I would go with a basic plugin and additional modules.
The plugin’s core functionality will be q and if you want to add functionality x, y and/or z, then you will need to install (an) additional plugin module.
The additional advantage to this is that you give other plugin developers the chance to develop something you didn’t think of on top of your plugin.
Both Gravity Forms and WPML (and I’m sure there must be others too) do this and it seems to work out quite well for everyone.
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.
Good thoughts. I think I’m mostly leaning in the same direction as you.
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.
Over the years, like everyone else, I found myself gathering snippets of code and adding them to the projects’ functions file.
After a while I spent more and more time configuring the plugin to fit and found it much easier to build as a plugin with simple on/ off options.
After about a year I finally found time to make this into a proper plugin and uploaded to WP rep:
http://wordpress.org/extend/plugins/point-and-stare-cms-functions/
It might not be the prettiest plugin in the world but it does tons of stuff simply.
Looks like a cool plugin from the screenshot. I’ll be giving it a test.
Great discussion going on here.
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.
I personally prefer on plugin that provides certain related tasks. In fact, my KC Essentials plugin (still in beta) is heavily inspired by how your Members plugin works.
As long as it’s done right (eg. the plugin only loads the needed modules/features), I think there shouldn’t be any overhead.
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.
Wow, I cared more about this issue than I thought. =)
Thanks for your thoughts. Getting opinions of users is what I’m after.
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.
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.
With my user hat on, I want fewer plugins, not more so lots of mini-plugins = bad in my view.
A large plugin with lots of optional functionality is better than a bunch of tiny plugins because it is much more manageable on the plugin and admin options screens.
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.
Larger plugins also means fewer plugins, and I don’t think anyone is well served by the chaos of the mostly unmaintained 17k+ plugins in the repository.
Larger plugins can gain the benefit of more user attention and thus more usage and, if the author can leverage it, more benefit for the author to maintain it.
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…
Thanks for the feedback, Mike. All great points.
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.
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 tend to lean toward “options when they make sense” or something along those lines.
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.
Hi Justin – great topic and awesome thread …
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.phpfiles. 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.
@Daimien:
You hit the nail on the head with those two. They issue has occasionally come up on hackers and trac, but always been shot down.
And so it goes…
-Mike
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.
Both have ups and downs. One plug-in is easier to manage but it seems like those 100-in-1 plugins just don’t perform as good as 1-in-1 plug-ins do. But at the end it all depends on the developers…
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.
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.
Why? If a plugin that performed a small task took care of some specific functionality you needed, why would that irk you?
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.
i personally like using multiple small plugins, but a big plugin for SEO.
Interesting ebate.
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).
I prefer small plugins, it will save loading time..
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”
I like using a big plugin for SEO, otherwise multiple small plugins.
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.
I prefer small plugins too