Why Plugins Sometimes Disappear From the WordPress Plugin Directory

Nearly 50K publicly available plugins call the WordPress plugin directory home but once in awhile a few of them seem to disappear. There is usually a good reason for why this happens but the only information available to the public is a page that says the plugin cannot be found. If the plugin is popular enough, concerned users will contact us and ask to investigate what happened.

Mika Epstein, Plugin Directory Representative, says there are a number of reasons for why a plugin can end up hidden from view, “The most well-known, but not the most common, is security issues,” Epstein said.

“Plugins are removed and, by default, hidden mostly because we’re on bbPress 1.0 and there is not as granular a control with post statuses when compared to WordPress itself.”

The plugin review team has three options to choose from when altering a plugin’s visibility, active, closed, and disabled. Although rarely used, when a plugin is disabled, it is hidden from view but updates are able to be pushed out.

I asked Epstein why there’s not more detailed information when a plugin is hidden and the answer is complex, “The lack of information is partly technical as bbPress 1.0 is limited and partly because we can’t all agree on the right way to disclose, when to disclose, and when not to disclose,” she said.

“Obviously the last thing we want are people getting hacked, but it presents us with a few options and they all have flaws. We’ve not been able to determine a way to tell people ‘This plugin is gone, don’t use it’ and ‘This plugin is gone, but use it if you want.’ without putting users at risk.”

Epstein uses WooCommerce and Jetpack as examples, “Let’s say I close Jetpack today and tell people ‘WordPress decided not to support it anymore.’ But tomorrow I close WooCommerce and tell people ‘I can’t tell you why.’ That means an intelligent person knows that WooCommerce is probably vulnerable.”

It’s a conundrum without an easy solution. The team typically closes plugins which makes the plugin’s page disappear. This has the added benefit of making it more difficult to determine if the plugin ever existed. Then the team contacts and works with the developer directly.

Most closures are done with the knowledge of the plugin author as they are often the ones who request that their plugins be closed.

The New WordPress Plugin Directory Will Modernize Plugin Administration

Announced at WordCamp Europe 2016, the WordPress plugin directory redesign has been in open beta for about eight months.

WordPress Plugin Directory Redesign
WordPress Plugin Directory Redesign

In addition to bringing a fresh new look to plugin pages, the migration away from bbPress to WordPress will help make the plugin review team’s job easier, “Like far too many things in Plugin Land, everything depends on modernizing the backend to something that is functional.” Epstein said.

“Once the new directory is out and I have some more people trained to do reviews properly, then we’ll have the bandwidth to sit down and really figure out a best solution.

“A stopgap might be making the page say ‘This plugin is no longer available.’ But I’m personally not sure if that would make FUD better or worse.”

If you discover that a plugin you rely on has suddenly vanished from the directory, don’t panic. Depending on the issue, plugins usually reappear within a week unless the author has requested that it be closed.

To learn what’s involved and how the plugin review team does its job, listen to episode 231 of WordPress Weekly. I also encourage you to read our detailed interview with Epstein published in 2014, in which most of the information is still accurate.

33

33 responses to “Why Plugins Sometimes Disappear From the WordPress Plugin Directory”

  1. I feel like I’ve been shouting in a vacuum, and no one ever hears exactly what I’m saying. It’s not JUST a matter of whether or not we know WHY a plugin disappears. You know what really matters? It matters that we know THAT it disappeared. Here’s why it matters so much. If a plugin disappears, and it NEVER comes back (which happens! – *contact form db comes to mind*), then possibly thousands of users – or more – will never ever know that they are running an old, probably outdated, possibly vulnerable plugin. Even if they go every day, every hour, or every minute, to their site’s plugin admin page, that plugin will never show them that there is anything wrong, never show them that it is old or outdated or vulnerable. For the next 599 years, they will never, ever know. Unless, they just happen to stumble upon a discussion about it somewhere, or they just happen to try to find the plugin page on wp.org. But the thing that is supposed to tell them about the plugins they use – their site’s plugin admin page – will never, ever tell them anything at all. Nothing. They will always think they have the latest, greatest version of the plugin. THAT. IS. WRONG. Please, please, core people, figure something out. Don’t push this under the rug because it is hard. You’ve done harder things. Thousands of times, you’ve done harder things. Not that I’m in the know, but yeah…I only have to use WordPress to know you’ve done amazing, wonderful, hard things.

  2. Sorry, had to re-post.

    I would agree Li-An, if we were talking about a service that we are paying for from the gate. We aren’t. There are services that will provide that type information but they are paid services. They are website management services.

    How much can we expect to have given to us? Those contributing to core and those maintaining the plugin repository and those contributing to the support forums are all pretty much volunteers. They provide a platform where different developers can provide free solutions for enhancing WordPress.

    What other obligations should WordPress volunteers and contributors be under? A weak solution would be to disband the plugin repository and we find other solutions all over the internet via Google.

    If there were no solutions to the issue, I could see the complaint. There are ways to find out what you want to know.

    How many other businesses out there would you be able to run and be notified immediately when something you were using was discontinued or back ordered, before you inquire, for free?

    And actually, Wordfence, from my experience keeps up with most vulnerabilities. I’m sure other security plugins do as well.

    • I don’t know if it’s possible but an automatic warning could be a solution. I don’t want the team to have more work.

      As installing a firewall plugin is not required and there is no warning about the danger to install a new extension, I think it can be improved. Most of users think that if something is working well now, it will always work. The plugins you listed could be included in the core.

    • Actually, no, “Plugin Directory Representatives” do not have the obligation to inform users regarding issues like this.

      I gave it a second thought and must say you’re right. Plugin developers instead of Plugin Directory Representatives should inform the public. And a notification on the official blog on wp.org can cause a quarrel between involved parties. But these are, as you have also mentioned, free available plugins so also developer has no real obligation towards the user.

  3. A good start is to remove plugins from the repository which cause errors on install and plugins which contain deprecated coding. Or at least inform the developer and give him/she some time to fix it. But I understand this isn’t possible with “nearly 50K publicly available plugins”..

  4. Plugins that haven’t been updated in over 2 years display a notice in the WordPress Plugin Directory; why not also display a similar notice in the summary details for a plugin in the WP admin area?

    That way users would be made aware of plugins that haven’t been updated in a long time (when they’re viewing their list of installed plugins).

    Another option, to specifically address plugins that have been removed from the WordPress Plugin Directory, would be to display a notice like: “This plugin is no longer listed in the WordPress Plugin Directory. No further updates will be available for this plugin, unless it is relisted in the directory.” Again, by this I mean displaying a notice in the WP admin area (installed plugins list).

    Of course this would only apply to plugins that link (or linked) to WP for updates, not plugins that rely on other sources for updates.

    • I think this is a good idea. Seing as closed plugins aren’t removed from the repository database, it shouldn’t require a lot of changes to the update flow.

      As far as I know, when checking for updates, a list of all installed plugins is sent to wordpress.org and a response tells which ones to update. This is also the reason why if you create your own custom theme/plugin with the same name as one in the repository, you’ll get an update notice for it.

      So I see 3 use cases in the update flow:

      1. Theme/plugin is active/hidden in the repository.
      Get update notices. (as today)

      2. Theme/plugin is closed in the repository.
      Get notice about no longer being maintained.

      3. Theme/plugin does not exist in the repository.
      Do nothing. (as today)

  5. Plugins are removed and, by default, hidden mostly because we’re on bbPress 1.0 and there is not as granular a control with post statuses when compared to WordPress itself.

    Well, am I the only one who sees a problem here. WordPress.org is running 5 year old code to run its plugin repository.

    Yeah, I know this is all volunteer supported and free for public consumption. But, why not update your plugin code base for your plugin repo?

    Kinda discourages the whole “update plugin for security issues” when the primary supplier of these updates can’t/won’t update the plugins they themselves utilize for this public service.

    I love the fact that WordPress delivers security patches separately for older versions of itself. This ensures that both compatibility remains and security stays up to date.

    It may be time to reevaluate how plugins get released. Delivering major releases ( v1.*, v2.*, etc.) parallel to minor non-breaking updates for security/bug patches.

    This way plugin authors can make small code adjustments as needed for security on, let’s say, at least, one generation of major release backwards while continuing to improve upon core features for the next major release.

    This would free up both website developers/designers and plugin authors from the constant upwards/onwards trajectory that ends up consuming lives.

    Sometimes better isn’t always, well, better. I’d rather have a secure website that functions without continuous overhauls then an always evolving mess that needs constant babysitting.

    It may seem like a step backwards that discourages improvements. However, in this 2017 world security trumps all other considerations. The high demand for continuous “improvements” in plugins is seriously undermining security on the web by discouraging the average user from updating plugins over fear that it’ll break their established sites.

    Hell, not even WordPress.org is willing to undergo the headache of updating its own plugin base.

    Just a thought,
    Chad

  6. Agree with Chad. Fix the plugin code base. But that might not be necessary for this particular issue.

    In the meantime, I have a suggestion, which might be a bad one, who knows, but it may at least spark a better idea. I’m against “notifying” users via blog post or even the plugin page itself, because it would mean users would have to stumble across those pages to find out the info. Sure, it would be better than nothing, but it would still leave thousands of users in the dark. The only good place to notify users is within their site’s admin – specifically on the plugin admin page. My idea: When a plugin is removed, a fake plugin (generic that is used over and over again) is put in its place. This plugin is designed so that it triggers the “this plugin has an update” notification on all sites using it. The big difference, however, is that when a user attempts to do the upgrade, nothing of the sort happens. Only a message pops up (kind of like how an error message pops up if the plugin directory cannot be connected to). The message can be generic. “Problem with this plugin exists. Check the status board for more info”. Then a link to some running list of current plugin problems is shown, where users can discover what’s going on. Core shouldn’t be deciding whether or not users should deactivate or not. Users should decide that. Core should merely be informing that there is currently a problem, which may or may not affect their site negatively. If it’s a temporary problem that is being handled, say so. If it’s a permanent problem (like the developer decided to remove it for good), then say so. All on the status board. Ok, that’s my idea. Hope it sparks something that can actually be done.

Leave a Reply

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.

Newsletter

Subscribe Via Email

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

Discover more from WP Tavern

Subscribe now to keep reading and get access to the full archive.

Continue reading