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

Plugin Improvements

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! 🙂

Published by Matt Pritchett

Matt is a Christian, a husband, a father to two beautiful girls and a WordPress developer at CrowdFavorite. He also creates software for nonprofits and enterprise customers at Pritchett Media.

Join the Conversation


  1. I think part of the problem with your proposed solution is that it only really tackles the issue after a plugin is causing problems. What the repo really needs is better discovery tools so that people can choose solid plugins from the start. This isn’t easy, and I don’t have any good solutions. But educating users is probably the area which has the most potential for improvement.

    1. Thanks for the comment Nate. I’m not sure exactly how to progressively check for incompatibility without a huge amount of effort and staff growth on the part of the review team. Even then, I’m not sure it is a possibility. My solution does allow for some semblance of sanity in this area but admittedly is not a complete solution. The problem with educating the user being an answer is often times we use it as an excuse to hide behind terrible UI, organization, and lack of innovation. Definitely things to think about as we move forward with core.

      1. As Matt Medeiros mentioned below, it’s more about improving search parameters, highlighting relevant information, etc. I don’t think you can really “scan” for incompatibility very well, but improving the tools people use to discover, rate and review plugins will help the discovery process a lot. The active installs feature is a great improvement.

    2. Going to echo what @NateWR is saying here, which I tried addressing with Mullenweg when I had him on the show.

      We (authors) need better exposure for our software. Improve rating score (read: score not system) and yesterday’s stats update is a small step in that direction. We need the means to declare better search terms and better landing pages for richer presentation imho. Again, recent plugin banner images helped along with the bump in UI.

      Like @NateWR, I don’t have a perfect solution, but since I’ve interviewed so many Shopify shop owners lately — their biggest benefit is becoming a Shopify partner. Something in that direction is a move that the .org should take. Automattic has one with a ridiculously high barrier to entry and price tag for their VIP solutions. A certified partnership or trusted author could be a solution — or just another way for the rich to get richer, not sure yet.

      I do know that Themes, on the other hand, get no love. That needs more attention than anything right now, imho.

  2. You both make valid points, and I believe solving both those issues is important. Even with better search/discovery tools to make quality plugins more prominent, incompatible plugins shouldn’t be displayed at all (so long as there was a reliable way to determine compatibility, as you suggest).

    I also think that plugins shouldn’t initially be allowed into the repo if the authors state in the description that they won’t offer support. I’ve seen it often enough, where an author writes a plugin and figures other people may as well benefit from it as well, but they don’t want to support/maintain it, and so offer it up “as is.” I’m sure there are other online locations where this sort of “project” can be showcased — and abandoned. The repo should be about quality, not quantity… That’s not to say there shouldn’t be any competition, of course. It’s just that WordPress has the opportunity/power to represent/portray itself at its best.

    1. Julie,
      While a valid point, I disagree on not letting plugins in that don’t offer support. Not every plugin needs support. Norcross and others release small dev plugins that don’t warrant support as developers should be the only users and if they can’t figure it out they shouldn’t be using it. While I agree that there are plugins out there that lack even basic support (that should have it), I also understand that not all need support and honestly supporting a free plugin (read: doesn’t produce money directly) through the WP.org system is a huge hassle and time suck. I’ve got several plugins that I am working on currently and I’m honestly on the fence whether to just leave them on Github or push them to wp.org because of this.

      1. I agree that plugins shouldn’t be required to offer support. But I think it would be great if a support policy had to be declared or might even be a search parameter. Options like free support, commercial support, maintenance and none would go a long way towards improving user expectations. And then I’d love to see moderators punt reviews that don’t conform with a plugin’s stated support policy.

        If a user wants to bitch and moan about the support they get for a plugin, they should only be able to do so if the support offered doesn’t match the support advertised. Entitlement should be discouraged.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.