WordPress has a plugin problem.
Now I know that there are plugins for this and for that. In fact, there are very few things that there aren’t multiple (if not hundreds) of plugins for. They are constantly being released. In fact, it seems that the plugin review team for wordpress.org always needs volunteers (I do understand that this is true of all volunteer teams)! 🙂
But as we move to upgrade the new user UX of WordPress as a software with the new user experience team, I believe that the plugin repo for .org needs to be addressed.
Plugins that are out of date or incompatible with current versions are a severe hindrance to not only finding plugins that work for your needs, but are also giving new users a terrible view of the WordPress ecosystem. This doesn’t even begin to cover the stigmas associated with WordPress at the enterprise level because of this issue (although there are others that are brought up in that space as well).
A major step forward was made with this problem back in XXXXXX with the addition of the “this plugin hasn’t been updated in 2 years” message. While it does help to let users know that this plugin may not work (and may is a big part of that sentence), it also is a glaring pain point for business owners and other non developer users.
While we also feature a compatibility “matrix” so to speak that allows for WordPress version compatibility checking with differing versions of the plugin, very rarely do I see that any input has been registered there.
A Possible Solution
I would like to propose what I’m sure will be a controversial solution, but what I believe has the potential to solve this issue. I’m proposing that incompatible plugins be placed on a temporary “maintenance” (or another, more semantic, identifier) list that removes them from the search results both on wordpress.org and in the plugin dashboard within core. This wouldn’t necessarily remove them from the repo (at least right away) but would place them “on suspension” from being basically advertised to millions of people.
There are issues with this approach, to be sure. How does one determine compatibility? Who does that onus fall on, the developer or the review team? Is it possible to automate the process? These are all valid questions that should be answered before implementation. But I believe with strong answers and implementation we would begin to solve an issue that plagues new and old users alike.
Got a better solution? Think this one will work? I’m less interested in credit and more interested in solving problems in our community and software. So let’s figure it out and tell me where I can help! 🙂