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?