Just last week, the WordPress plugin repository passed the 30,000 plugins hosted mark. This is, of course, an incredible achievement and one that reflects both the magnitude of the WordPress project and the spirit of its community. It also got me thinking. 30,000 is a lot of plugins.
There are many plugins that are outdated, ineffective, and potentially harmful to WordPress installs. Finding those, however, can be a daunting task, and regulating them can be even more difficult.
I began thinking out loud on Twitter, and was able to come up with a few suggestions. I think that it’s certainly a problem worth investigating, and one with several possible solutions (possibly none of them ideal). This article is simply exploring a few possibilities. I’d like to hear more—lots more—from the community.
We Need Less Plugins
There are a lot of plugins out there. But the good ones tend to bubble to the top, and we don’t have to download or try all of them.
There are a couple reasons why we need to strip the list down. For one, there are some plugins out there that have slipped through the cracks and will absolutely break your site. We need a way of finding and removing these plugins from the repository.
The second is sustainability. In your average week, there are over a hundred plugins added to the repo, and it’s only growing. The opportunity for overlap, frivolousness or dysfunctional plugins is only growing. What number is too many. 50,000? A million? We need to introduce some stop gap measures to make sure that only the best and most usable plugins surface in the long term. That brings us to our next question.
What Makes a Bad Plugin?
When it comes to bad plugins, you know it when you see it. But that’s really not specific enough. There are many factors that can make a plugin “bad.” Poor support, infrequent or nonexistent updates, improper compatibility, or lax security. The current plugin review standards prevent a great deal of this, but it can’t prevent everything. Additionally, it can do very little about plugins that have already made it into the repository.
There isn’t a single cutoff line or standard we can point to to identify a “bad plugin.” It just creates an awful experience for its users. But just because a plugin hasn’t been updated in three years doesn’t mean that it won’t be valuable for somebody today—or in perfect working order. It’s very difficult to qualify that criteria though. Determining bad plugins is almost a subjective affair and hard to boil down to a single process.
So what can we—the WordPress community—do?
The first thing that leaps to mind is to create stricter guidelines for plugins allowed in the repo, and apply this new criteria retroactively to existing plugins. For new plugins, this would mean determining the relevance, originality, and quality of plugins that are coming in.
The plugin review team, as it turns out, is a bit stricter than you might think. They check to make sure that new plugins aren’t duplicating existing efforts, and test plugins thoroughly for security and code errors. Still, many plugins that get through that don’t pass through WordPress’s debug mode successfully, so we may need to tighten our grip a bit. And there’s still a larger problem. Once plugins are already in, how can we monitor updates to ensure consistency and reliability.
That’s where part two comes in. Remove existing plugins based on certain criteria. I won’t go into too much detail here because it falls apart fairly quickly.
What criteria can we use for removal? Time since last updated seems like a fair one—except when you consider that some old plugins work just fine and developers may still rely on them. How about number of downloads or time since a plugin was last downloaded? Well, should a plugin be penalized because no one has downloaded it in a while? Can’t it still be useful?
It becomes clear quite quickly that in order to keep the WordPress plugin repository “open,” the way it should be, we would need help from the plugin developers themselves.
A promising idea came from Christian Foellmann. He suggested that what we might need is to reach out to developers directly. I can see this unfolding in two ways.
@jay_hoffmann Maybe setting up a “platform” to bring devs/projects together is a thing worth exploring?
— Christian Foellmann (@cFoellmann) March 21, 2014
The first would be to create a platform to connect plugin developers. Think of this as a sort of social development tool that allows you to easily check existing plugins—and plugins in development—to see if your idea is being worked on. That way, instead of reinventing the wheel over and over, we can encourage collaboration and reduce redundancy.
The basic concept would be to create a directory that allows developers to check in—and work on each others projects with ease—while making code and idea sharing very simple. Platforms such as GitHub have a lot of the infrastructure necessary for this already, so it may be possible to build off of something that already exists. Getting developers to use the platform might be a whole different issue, but it’s definitely worth exploring.
Another approach may be to—more aggressively—reach out to plugin developers to encourage them to phase out underutilized plugins, and plugins that haven’t been updated for a while. This would mean identifying the “low hanging fruit” (low number of recent downloads, no recent updates, very poor support), and then reaching out to the developers of these plugins. This would provide insight to see if there is a way to either merge the code with another plugin, or remove it altogether.
This can be useful for culling down the list of plugins that still technically work—but may no longer be necessary, or all that useable. It would require a bit of effort to identify plugins, find the developer behind them, and hope they reply. But it could be a way to remove some plugins slowly—while still keeping everybody in the loop.
My last suggestion is a bit simpler. One of my biggest frustrations with the plugin repository is that it can be very, very hard to find what you’re looking for. When you search for plugins, it can be hard to tell why certain plugins are at the top of the results. Rating systems are also confusing and can be misleading, and categories and tags have expanded well beyond control.
Perhaps the most useful navigation tool on the site is a little alert box that indicates if a plugin hasn’t been updated in over 2 years. The problem is, you can only see this warning once you reach the plugin description page.
I’d like to extend this out by creating an overall “archive” flag that can be applied to any plugin. This flag would indicate that a plugin falls within range of criteria including: not updated in over two years, unresponsive on less than 25% of support forum posts, downloaded less than 10 times in the past 30 days, etc.
This flag could be called out on the front-end of search results, categories, and plugin descriptions. That way, users can still use the plugin—but they know to be cautious with it, and they don’t have to dig past the front page of the search results to find it. Coupled with some better categorization of plugins in the repo and fine tuned search results, this may be a crucial first step on the right path.
If we manage to fix these problems, then I might be out of a job. But still, I’d say it’s worth it. I’m interested to hear from you.
What improvements do you think we could make to the WordPress Plugin Repository?
Jay Hoffmann is a WordPress developer hailing from NYC. In the strictest sense of the word, he is a WordPress enthusiast with an eye for front-end development and design. He has been working with WordPress since 2006 and currently works for a popular children’s media company. This year, Jay started Tidy Repo, a curated list of the best and most reliable plugins from around the web. You can also follow Jay on Twitter.
Join the conversation