Closing Unused Plugins

When you submit a new plugin, we get to see every single plugin you’ve ever submitted. This means we also see how many plugins we approve that people never use. At this moment, there are over 9100 plugins approved and unused.

Edit: Unused means LITERALLY unused. No one uploaded code. Ever.

Because of that, we’re going through and closing unused plugins if it’s been 6+ months since the plugin was approved. In addition, if we notice a pattern of behaviour, where you are submitting multiple plugins and not using the provided hosting, we will pend any new submissions until you actually use the directory.

The good news about this is once we close it, people can request to take over the slug and use it for a new plugin.

Remember: Every time you submit a plugin, a human being downloads and reviews your code. If you’re submitting with out a plan to actually use the hosting, you are abusing the finite resources, and taking away from everyone else who is using the directory. Worse, we’ve found out some people like to get a review as a ‘free’ security review instead of hiring people for that work.

Most of you, this won’t impact in the slightest. After all, you use the hosting 😀

And of course, if you have a plugin you don’t want to host anymore, you can always ask us to close it (though please read the FAQ on Closing Plugins first).

Is there anywhere that developers can see a list of their own plugins that might come in this category? I don’t believe I have any such, but a) a lot of things happen during a decade and b) it might be used by some people who do have them to save you some time.

Worse, we’ve found out some people like to get a review as a ‘free’ security review instead of hiring people for that work.

I wonder if an appropriate response to that would be to go ahead and publish the code in SVN, but flag the directly entry CPT as if it hadn’t been updated in 2 years, so that it wouldn’t show up in search results. That way, the code is open sourced for others to use, but users won’t end up installing an unsupported plugin.

It might alter deter unscrupulous people, since they tend to want to keep their code private.

They usually don’t make GPL compat code, so we’d have to remove it anyway. Also we don’t auto-publish plugins like we do themes. Once I approve a plugin, our zip copy is deleted.

Ever since we blocked people from being able to submit more than one plugin at a time, the attempts dropped. It might be worth looking into blocking submissions if you have 2+ plugins that are approved but not active (i.e. no code committed).

So… I have some plugins that I’ve registered but never uploaded. My reason for doing so was because I had the plugin hosted off wordpress.org and I didn’t want someone to come along and use the same slug and for my users to suddenly get an update for a different plugin.

I know there are ways to code around being over-updated by a wp.org hosted plugin, but there are flaws with that. I know there is a trac ticket somewhere to help prevent this too. But reserving the slug was the most foolproof way of ensuring users weren’t messed around…

It doesn’t affect me too much now as I no longer support any of my plugins hosted off wp.org, so if they get overwritten… I guess that’s just bad luck for the users… 🙁

I would like there be a proper solution to prevent that though, so I hope that trac ticket eventually sees some progress.

See, the plugins directory is a hosting site, not a listing site. Plugin entries which are unused in the directory are not “blocked off”, since if you don’t use it, then we can and will take it away from you and give it to somebody else if they ask for it.

In other words, use it, or lose it. If anybody came along and said “can I have this unused slug” then the answer is “yes”.

To add on to Otto, remember that we have no way to know that’s why you namesquatted. Unless it’s a trademark, we’re likely to say yes to any request and just let you know that your unused name was given to someone else.

This is great – happy to hear about this. I have a few plugins that I built several years ago and after some time did not get the traction I was hoping for… and thus active development on them has basically stopped. I wanted to close them down – but at the time the recommendation was to leave them open as others may use them. It would be great if there was a way to mark a plugin as “Abandoned” or “No Longer in Development” so that an author can indicate that they are no longer able to work on a given plugin. If such a method already exists – I would love to know about it. Have a great day.

What Jeff said 🙂 We tend to leave those alone unless the service they use gets deprecated (so like when Twitter switched to API2, we closed the unedited API1s…) As long as they work, we’ll probably leave them alone. That said, it’s also okay to ask us to close them if you don’t think anyone will adopt them. Both are valid choices 🙂

It’d be good to mark plugins as deprecated and hide them from profiles and not have them in search. So they do exist and are not closed, but aren’t actively promoted. There may be cases where a plugin should still exist like it is active, but not actually promoted and visible to those that don’t explicitly want/need it.

I appreciate everything on the wish list needs building. I would if the meta environment was easy to setup! 😀

Anyway, this is a welcome change. Would be good to see what names have appeared on the 9,100 list too.

Ehhh. We’ve tossed that idea around, but the issue is how to properly separated ‘deprecated because Twitter closed it’s API’ from ‘deprecated because I have a new plugin that does it better’ from ‘abandonware’ from ‘merged into core’.

That last one, we have sorted out as an option, but the others are used pretty indiscriminately by developers (and I can’t blame them, English is weird), so it’s actually a lot of by-hand work to figure out what was meant for each one.

In general, the ones that are deprecated from an API being shut down, we close when we spot.

If they’re deprecated because there’s a new plugin, we’re getting better about catching those BEFORE approval and try to talk you out of it. Most of the time people do this to ‘fix’ the URL, but it means you lose your users, all your link-juice, and there’s no way to forward people. So … y’know, just rebrand. Unless there’s a trademark situation, the URL being ‘off’ isn’t as big a deal as you think.

You mean a public list? No. It’s insanely unwieldy at the moment. Also a lot of the URLs are ones we’d not be able to let people use anyway. At least now, though, if you try and submit a plugin with the name, or go to the URL to see if it’s in use, you’d see it was closed 🙂