To Free Up Resources, Plugin Review Team Begins Closing Unused Plugins

In an effort to free up resources on, the WordPress Plugin Review Team is closing unused plugins. An unused plugin is one that has been approved for the directory but no code was uploaded by the developer in six months or more.

An unused plugin reserves a URL slug on and prevents others from using it. It also takes resources away from active plugins. In addition, if plugin authors are submitting multiple plugins without taking advantage of the resources offers, submissions from that author will be suspended. provides plugin authors free hosting as a convenience and is not a listing service. Mika Epstein, a member of the plugin review team, says that some people have taken advantage of the submission process to receive a code audit, “We’ve found out some people like to get a review as a ‘free’ security review instead of hiring people for that work.”

To find out what happens when a plugin is closed and how to close a plugin you maintain, check out this guide in the Plugin Developer FAQ. Also, if you want to use a plugin name that’s currently held by a closed, unused plugin, you can request to take over the slug by contacting the review team.


20 responses to “To Free Up Resources, Plugin Review Team Begins Closing Unused Plugins”

  1. They should also start removing plugins that were not updated for 5 or more years. Current plugins number looks high, but, number of active plugins are much lower. They started marking outdated plugins few years ago, but, that ultimatively did nothing to really cleanup the repository.

    • Yes, removing broken plugins (that were broken by new releases of WP and the author did not update) is a good idea. The problem is, how to find and identify broken plugins and remove only those?

      I mean there might be some X year old ones, that are still working flawless, so removing just based on the age is questionable IMO.

      • Maybe combine age and number of downloads in recent years. I think thst has plenty of data to filter out plugins to remove.

        Also, som outomated testing with various versions of WordPress can reveal broken plugins to.

    • It’s not that easy to assess if a plugin is broken or not just by it’s age or not being tested with current or recent WordPress versions. A first step could be, IMHO, to have the search algorithm penalize older plugins in search results. Current search is weak and allows very old plugins to appear on top of results.

    • It should be very careful to remove old but working plugins. Some plugins don’t need to update over the years, but they still work perfectly.

  2. How would a user download the plugin to use it if the author never uploaded the code to the .org repository in the first place? Note that unused here means the code was never uploaded to the directory after it was approved.

    • Okay, then i misunderstood. I just thought if the plugin author does not upload updates then it would be declared “unused”. Thanks for the clarification!

  3. While removing outdated plugins is a good start, providing filtering capabilities and bolean searches on the data already in the repo would be nice too : # of stars, # of downloads (interval), compatibility with current WP version, last update date, etc.

    • Agreed. Current filtering capabilities in both plugin and theme repositories are atrocious.

    • Good move. I’m sure I have a few plugins that I submitted for approval but never actually released.

      If I remember correctly a plugin file upload wasn’t required back in the day.

  4. “We’ve found out some people like to get a review as a ‘free’ security review instead of hiring people for that work”

    So for many non-commercial plugins you require authors to spend money on something which they not benefit financially ?

    • You did not understand clearly : the code was reviewed by the team but was never uploaded on the depot. So the developer had a free check but did not share any work. So, it’s not a “non-commercial” plugin as it’s not distributed in the depot. And, worse, it can be a commercial plugin.

  5. Shuttting a plugin is one thing but allowing a new developer to take over an existing plugin (without the authors approval) is problematic.

    Legally a plugin author could have common law trademark on the name…

  6. Good start. As others have said here, a great next step would be to start working backwards from the oldest, least updated plugins and culling the herd even more. But I’m happy with this move.

    • The main issue with that is: There are quite a few plugins around which simply DO NOT NEED updating.

      Eg. Regenerate Thumbnails got no updates for over 6 years – because it was working flawlessly. Only after excessive head shaking and strong nudging, the original author started overhauling it.

      IWhen looking at its usage statistics, you see that quite a bunchload of users still prefer the 2.x releases. Which might be a) one doesnt trust the rewrite or b) the 2.x AGES OLD release still works flawlessly even in the current WP nightly builds.

      Of corpse, I do understand that nowadays, folks think that updates are an indicator if a piece of software has been or has not been abandoned for good. Which is well-meaning, but shortsighted. Because: NTARS.

      cu, w0lf.

      • It has since been clarified that those won’t be removed. This sweep appears to be against plugins that were registered by the author, but never fully uploaded. Which is a good thing to remove.

  7. What about providing notifications in WP admin backend plugins list if a plugin has not been updated for 1, 2, 5 years or has been removed or suspended from repository? With maybe a vertical color bar left/right in yellow, orange, red, purple or similar?

    That would really be helpful.

  8. That’s a good move. I’ve seen several plugins that haven’t been updated for years, and that are still downloadable. Some still work, most don’t. They also pose security risks to WordPress users. Hopefully, this will force plugin authors to keep their plugins updated.


Subscribe Via Email

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

%d bloggers like this: