Cancel

Jeff Chandler

Plugin Quality Not Plugin Quantity

Ryan Imel of WPCandy.com has published an editorial that has sparked yet another good discussion. This time, the focus is on the misnomer that it’s better to keep your active plugin count as low as possible to avoid problems.

I’ve been down this road before. In at least a couple of the WordCamps I’ve attended where we discussed plugins, I would tell folks that I had almost 30 active plugins running on WPTavern.com. Judging by their reaction, you’d think I just dropped a bomb on them. In my defense, those 30 or so plugins enabled me to have the functionality I wanted within a WordPress installation. For the most part, these plugins have caused me 0 problems. The total number of active plugins has varied between more than 30 and less than 25 over the past four years but I’ve never had more than 35 activated at one time. After 4 years of using WordPress, my activated plugin count has remained nearly the same for two reasons. The first is that I’m pretty content with the functionality I have. The second is that I’m not the adventurous type who likes to try every plugin known to man.

The funny thing about this discussion is that, you could have 3 plugins activated with one of those causing your site to hang. Or, you could have 25 and your site loads in less than 3 seconds. As Ryan mentions, the number of activated plugins doesn’t matter so much as the quality of the code within them. This conclusion leads us into an entirely different subset of circumstances. For instance, how do you judge the quality of a plugin before installation? How does one know if a particular plugin doesn’t play nice with some other plugin? Are we to sit here and expect end users to know good code from bad? From my perspective, if I activate a plugin and it provides the functionality it says it does, I generally don’t go under the hood to see how it’s done, just as long as it’s done without any apparent issues.

In a perfect world, we should be able to activate 100 different plugins from a variety of different authors and have them all work seamlessly without any problems. But this isn’t a perfect world. It’s open source. It’s the wild wild west of coding. Sure, there are coding standards for WordPress, but not everyone is going to follow them. Not everyone is going to do things the way they should be done because it’s an open world. A plugin review team that works similarly to the theme review team is non-existent allowing plugins that don’t have malicious code into the repository regardless of their code quality. So how does this problem end up getting solved for everyone involved? It doesn’t. We can continue to educate both users and developers until the cows come home but the very nature of how things work in this open source environment allows for bad code quality to happen. It’s the nature of the beast. I think that over time, the problem can become less of an issue but it will never go away. Not unless some major crackdown starts happening on the plugin repository. Educating plugin authors is a good way to treat one of the symptoms of the overall problem but screening code before it gets past the pearly gates of the repository into the hands of users is the only way to truly solve the problem. Just like the theme review team, until a plugin reaches certain quality criteria, it can not be allowed to be hosted on the repository. It may sound bad, but the repository gate keepers would be the ones educating plugin authors before their code is accepted so in the end, it would be win-win situation.

This could cause some plugin fragmentation in terms of where people go to get their plugins but that has existed for years. It might even cause a backlash similar if not, worse than the one generated from implementing the theme review team. But at the end of the day, something like this is good for end users all around. There certainly would be no guarantees that everything will work seamlessly after the team is put together but what it would be doing is increasing the odds of that happening in the future. It would also increase the number of plugins hosted on the repository that can be used as examples of plugins that did things the right way.

However, a plugin review team introduces it’s own complexities such as how many people will be on the team, will only new plugins be screened or all plugins pushing updates to the repository, will these volunteers be paid etc. The funny thing is, if only new plugins were screened on the repository, it would mean that potentially down the road, an update to that plugin would introduce shoddy code which in turn would break someones site.

After thinking about all of this, I start to wonder if it’s a case of “just can’t win“. Perhaps it’s best to educate users and developers as best we can and hope for the best?

Related But Not Required Reading:

Validating Plugins
Quality Check Your WordPress Plugins
Finding Quality WordPress Plugins
WordPress Plugins: How To Know If You Have Too Many

Category:
Tags: , ,
9

9 responses to “Plugin Quality Not Plugin Quantity”

  2. Jeffro:

    It’s amazing how well most plugins work with WP and other plugins. Sometimes I’ll find a plugin that conflicts with another or doesn’t work as advertised. In that case I look for another plugin and most of the time find a different one that works. One could argue to leave well enough alone.

    On the other hand, WordPress has become increasingly popular as a website software. More and more online businesses are using it for their websites. As a business owner, you’d like to be assured of some level of quality because when you’re site is down, you aren’t making money. From this perspective you could argue that there should be a review process.

    Maybe we should look at it as a tiered plugin repository – quality reviewed plugins and non-reviewed plugins.

    Should plugin reviewers be paid? If so, why not pay the theme reviewers?

    Maybe theme and plugin submitters should pay a fee for reviews?

    Create forum topic from comment

  3. The truth is, what makes me nervous about a high volume of plug-ins on a site is the sad reality that many plug-ins are simply poorly developed. Even if they work in a sandbox, they often don’t work well at a high traffic scale. You might get away with a few so-so plug-ins, but the odds of a badly developed plug-in taxing your site get higher the more plug-ins you install, and the more bad plug-ins you run, the worse the problem becomes.

    Even many well developed plug-ins have become insanely bloated, adding layers of code to WordPress execution for features most users will never touch. And I speak as the author of about 15 publicly available plug-ins.

    The reason I built Simple Local Avatars, for instance, is because *popular* plug-ins that were once simple solutions (like “Add Local Avatar”) have become – in my humble opinion – far too heavy and bloated. I don’t want that weight sitting on top of WordPress. I wanted a plug-in that added an avatar upload field to the author’s profile, and would use that avatar – if available – when an avatar was called. No new setting screens (there is a single new setting option in the Avatar section of Discussion — where it belongs — that lets users determine whether lower permission roles are allowed to upload avatars), no third party API communication with social media sites, no new dashboard widgets promoting the author, no new folders in wp-content. I had to build the answer.

    I’m not sure what the answer is, but I often see adding lots of plug-ins to WordPress as akin – in many cases – to all the freeware software people used to install on Windows. We all know how that ended up working out.

    Create forum topic from comment

  6. Why not start small? Some script/program which scans for typical mistakes. Initially it could just grep for things which are a no-go but are known to be used, maybe also some typical novice-mistakes, and some bad-programming-style things. Maybe also grepping for things which should be there but are forgotten from time to time.

    With this as a base (and I’m sure as time increases the things which are looked for in such a program will increase), the basic quality could improve for the worst plugins. Provide this to the people to check before submission of the plugin, so that people can check locally, and also run them for each new submission to the plugin-repository. Initially you could just issue a response from the output of the program to the authors, later you could maybe block based upon the output.

    As an example what is possible with such a script you could have a look at “portlint” (http://www.freebsd.org/cgi/cvsweb.cgi/ports/ports-mgmt/portlint/src/portlint.pl), the script which checks the meta-data of the FreeBSD package management system.

    I’m sure as time passes such a script/tool would receive improvement submissions and extend into something which catches a lot of problem cases.

    I’m aware that this will not be able to find everything you want to find, and that some things may even be imposible to find with such a tool, but you can raise the bar by a good amount to what is done in the plugins ATM.

    Create forum topic from comment

  7. Should plugin reviewers be paid? If so, why not pay the theme reviewers?

    As a Theme reviewer: I say absolutely not. The WordPress project likely doesn’t have the funds, and WPF might have a difficult time justifying such an expense as a 501(c)3 organization. So: who ends up paying? The only viable source is Automattic, which would be an inherently bad idea, IMHO.

    Maybe theme and plugin submitters should pay a fee for reviews?

    Again: absolutely not. It is imperative that reviews remain fair and objective. Introduce financial incentives/contributions from Theme/Plugin developers, and that fair/objective standard becomes infinitely more difficult to maintain. Heck, the WPTRT has already had to defend itself against accusations of taking money for approvals, and/or for the Featured Themes listing; imagine if actual money was involved.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.