95 Responses

  1. Jay
    Jay Published |

    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.

    Reply
    1. Tomas
      Tomas Published |

      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.

      Reply
  2. Rahul Bansal
    Rahul Bansal Published |

    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!

    Reply
  3. Michael Bishop
    Michael Bishop Published |

    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.

    Reply
    1. Daniel Dvorkin
      Daniel Dvorkin Published |

      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.

      Reply
      1. Daniel Dvorkin
        Daniel Dvorkin Published |

        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.

      2. Daniel Dvorkin
        Daniel Dvorkin Published |

        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)

    2. Rahul Bansal
      Rahul Bansal Published |

      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. :-)

      Reply
  4. Patrick Daly
    Patrick Daly Published |

    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.

    Reply
    1. shawn sandy
      shawn sandy Published |

      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.

      Reply
  5. shawn sandy
    shawn sandy Published |

    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.

    Reply
  6. Thorsten Ott
    Thorsten Ott Published |

    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.

    Reply
    1. Alejandro
      Alejandro Published |

      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 . . .

      Reply
  7. jzigbe
    jzigbe Published |

    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.

    Reply
  8. Thiago Senna
    Thiago Senna Published |

    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++

    Reply
  9. JLeuze
    JLeuze Published |

    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.

    Reply
  10. Piet
    Piet Published |

    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.

    Reply
  11. Mark Wilkinson
    Mark Wilkinson Published |

    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.

    Reply
  12. Παιχνίδια Στρατηγικής

    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.

    Reply
  13. Lee Rickler
    Lee Rickler Published |

    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.

    Reply
  14. Jason Coleman
    Jason Coleman Published |

    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.

    Reply
  15. Mario Peshev
    Mario Peshev Published |

    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.

    Reply
  16. Dzikri
    Dzikri Published |

    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.

    Reply
  17. Simon Fairbairn
    Simon Fairbairn Published |

    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. =)

    Reply
  18. Erlend Sogge Heggen
    Erlend Sogge Heggen Published |

    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.

    Reply
  19. Mike Schinkel
    Mike Schinkel Published |

    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…

    Reply
  20. Sue Surdam
    Sue Surdam Published |

    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.

    Reply
  21. chuck scott
    chuck scott Published |

    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

    Reply
  22. Iva
    Iva Published |

    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).

    Reply
  23. Chris Schmitz
    Chris Schmitz Published |

    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 :)

    Reply
  24. Damian Gostomski
    Damian Gostomski Published |

    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.

    Reply
    1. Mike Schinkel
      Mike Schinkel Published |

      @Daimien:

      1. There is no proper dependency management system for plugins.
      2. The plugin screen would become a mess.

      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

      Reply
  25. Ben Huson
    Ben Huson Published |

    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.

    Reply
  26. Adrian
    Adrian Published |

    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!

    Reply
  27. Paul Johnson
    Paul Johnson Published |

    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.

    Reply
  28. Sean Conklin
    Sean Conklin Published |

    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.

    Reply
  29. Rick
    Rick Published |

    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…

    Reply
  30. Neil Davidson
    Neil Davidson Published |

    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.

    Reply
  31. Ejaz Siddiqui
    Ejaz Siddiqui Published |

    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.

    Reply
  32. Ashlife
    Ashlife Published |

    i personally like using multiple small plugins, but a big plugin for SEO.

    Reply
  33. Giuliano
    Giuliano Published |

    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).

    Reply
  34. Kotaro
    Kotaro Published |

    I prefer small plugins, it will save loading time..

    Reply
  35. grandt
    grandt Published |

    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?

    Reply
  36. Average Joe
    Average Joe Published |

    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”

    Reply
  37. JB
    JB Published |

    I like using a big plugin for SEO, otherwise multiple small plugins.

    Reply
  38. WordPress: il problema dei plugin | Gabriele Romanato
  39. Nadeem Khan
    Nadeem Khan Published |

    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 !

    Reply
  40. BJ Johnson
    BJ Johnson Published |

    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.

    Reply
  41. Foie Gras
    Foie Gras Published |

    I prefer small plugins too

    Reply
  42. anmari
    anmari Published |

    No one right answer imho – it’s a judgement call on each set of functionality as to what is a cleaner solution. I’d like to emphasis what Jason said http://justintadlock.com/archives/2012/01/21/one-massive-plugin-vs-several-mini-plugins#comment-571238

    Also:

    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….?

    Reply
  43. Samuel
    Samuel Published |

    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.

    Reply
  44. John Pratt
    John Pratt Published |

    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”?

    Reply
  45. Mike Levelchek
    Mike Levelchek Published |

    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).

    Reply
  46. Randy Steer
    Randy Steer Published |

    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”.

    Reply
  47. Kaiser
    Kaiser Published |

    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.

    Reply
  48. Mick fallon
    Mick fallon Published |

    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

    Reply
  49. Alan
    Alan Published |

    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).

    Reply
  50. Joe
    Joe Published |

    I prefer several single-task plugins.

    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.

    Reply
  51. Shawn Ang
    Shawn Ang Published |

    Doesn’t really matter to me as long as the job is done.

    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.

    Reply
  52. Liana Mir
    Liana Mir Published |

    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.

    Reply
  53. scott
    scott Published |

    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.

    solving a specific problem with elegance is a great goal.

    Reply
  54. Convention over configuration in WordPress themes/plugins | 7 Degrees
  55. Home Depot Coupon
    Home Depot Coupon Published |

    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.

    Reply
  56. indocitycar
    indocitycar Published |

    I prefer to choose several mini plugins than use one massive plugin. However, it is something confusing like SEO or custom taxonomies, codes, etc.

    Reply
  57. Web Writing: The Editorial Article | Learning from Lorelle

Leave a Reply

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.

css.php