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.

    • Hi Donna Cavalier,

      There is a plugin that can help users find out if a plugin is no longer in the repository. That plugin is No Longer In Directory.

      Also, there are plugins that help us know more about plugins, when they are updated, if they haven’t been updated in a long time and such.

      One of those plugins is Vendi Abandoned Plugin Check

      There is also a plugin that gives information on the latest version of WordPress and BuddyPress each plugin is tested to.
      This plugin gives that information.
      Better Plugin Compatibility Control

      I’m sure these most likely aren’t the only plugins to help with this. I have just grown used to using them.

      While it is frustrating sometimes with the level of free flowing information coming from WordPress volunteers and anyone associated with the WordPress community of contributors, I have learned that it is still be best maintained and easiest organization to work with of those I have checked out.

      Nothing is perfect. That’s for sure. But when it comes to WordPress and the plugin repository I haven’t seen anything that comes close to matching it. Yes, core notifications could be better. They could use a more updated version of bbPress. And there is usually a plugin available that will make up for those things not in core.

      I have spent a lot of time in the plugin repository (over the course of a few more than a few years) searching for things that help users of WordPress. There is a lot there. Their search function isn’t the best and isn’t very intuitive, but if you keep at it, you will find a lot of useful things there.

      I know there are things I would like to see in Core. But if everyone had what they wanted in core, many people wouldn’t have fast enough internet to download WordPress in a reasonable amount of time.

      I think the plugins above would give most people the information they need. There are also plugins that help protect sites from vulnerabilities.

      Just one of those plugins is Wordfence. I have used if for years.

      They are all free and have been reliable for me. For the most part, they don’t take up much space and don’t bog down a site too much.

        • Interesting question. Why would the average user know what to do when a plugin is no longer in the repository?

          You are trying to present an unrealistic argument. If someone is working with plugins, and they need to know if they are no longer in the repository, then they have to know what to do if that plugin is no longer available.

          To use your argument, we would need not only automatic updates, but also automatic replacements. I suggest you are creating a separate problem.

          The problem is solved with plugins.

      • I agree with Donna. This is a mess. And I cannot also understand why WordPress doesn’t have a security hardening plugin, a backup plugin and a cache plugin built into core. This is basic stuff that is needed on (almost) every website. Core team is way out of touch with the needs of users.

        • During the WordPress 4.7 development cycle, Rand-Hendriksen said he was involved in several conversations where participants assumed the use of features without any data to back up their opinions. He contends that WordPress contributors do not have the necessary data to know how users are interacting with the application and its features.

          “The general argument was that based on the 80/20 rule, certain features should be added while others should be removed,” Rand-Hendriksen said. “I kept brining up the well known fact we don’t have a clue what features 80%, or even 20%, of WordPress users actually use so any claim of validity in the 80/20 rule is guesswork at best.”

          Lack of proper data and assumptions based on confirmation bias in core… Seems they aren’t really analyzing what’s needed, just going by hunch and responding to ‘market noise’…

      • This is a perfect example. It had a vulnerability. You are therefore probably running the insecure version. What you don’t know is that repo pulled it, one of the core people got into some kind of disagreement with the plugin author, and the author moved the plugin to github. Now, even if the author fixes the security, you’ll not only never know about the fix, you’ll never know there was an issue to begin with. Your WordPress admin will keep making it look as though your plugin is perfectly up to date and fine. But core knows it isn’t. They just haven’t bothered to figure out a way to let you and the other thousands of users know. And please, none of the “this is free so get over it” or “this is hard” stuff. Yeah, got it. Free. Volunteers. Yep. Now, can we get back to the problem? If you’re interested in seeing the thread I stumbled on about the db plugin, it’s here: https://wordpress.org/support/topic/plugin-is-missing-on-the-wordpress-org-directory/

        • Hi Donna, thanks for informing me about the thread, did not know about this… And you’re right, removing a popular plugin like CFDB without telling why creates confusion. IMO, the Plugin Directory Representatives have a obligation to inform users regarding important issues like this. Easy solution: they can inform users via the blog on wp.org (add an extra category for notifications).

        • Actually, no, “Plugin Directory Representatives” do not have the obligation to inform users regarding issues like this. Plugin Directory Representatives have taken it upon themselves to remove dangerous plugins. It is the responsibility of the Plugin Developer to correct the problem and get the plugin back online as soon as possible so that vulnerabilities are remedied.

          Easy solution:
          Upon notification of a problem to the Plugin Developer, that person makes the correction. If you want to be upset at someone for the plugin not being available it should be at the person who is too busy to fix the plugin they have available to the public.

          Regardless whether the developer is upset with WordPress or not, the person or company placing their plugin in the Repository has the obligation to those using the plugin (if there is any presumed obligation).

          Gimmie, Gimmie, Gimmie is not the best approach to solving issues, IMHO.

          We always have the choice to use another project for what we want to accomplish online. That’s the way I look at it.

          Too much expectation is being thrown upon volunteers who do a great job (however you may look at it), who also have a regular job on top of providing a free service to the public.

        • I don’t know how to reply to Central Geek – seems like we can’t reply that far in the comment chain? So I’m replying here – sorry.

          Absolutely disagree with you, Central Geek. Vehemently and with every fiber of my being. Of course it’s the plugin developer’s responsibility to fix it, but the Directory removed it – so the directory should notify the plugin users. I’m sitting here learning about Contact Form DB for the first time – and I have it installed on our live site! If you remove the plugin for security reasons – don’t you think the people with it installed on a live site should be notified?? We’re the ones now using an unsafe plugin on our site with absolutely zero knowledge of the problem. My Contact Form DB is sitting in my site’s backend, happily chugging away, with zero notice of any security issues or risks. And there’s no way for the developer to contact me to let me know, because the plugin was pulled.

          This isn’t a complicated concept. Even an automated system would fix it – but the only ones with the ability to notify are the Directory folks, and the users need to be notified. There’s only one option at that point. The Directory must notify the users.

  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. The Plugin repository is awful. When I search for a plugin, I should be able to filter how many active installs it has. Instead, I have to scroll through a bunch of plugins with less than 100 installs to get to ones that have 600,000 active installs. It forces me to waste time.

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

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

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

Newsletter

Subscribe Via Email

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

%d bloggers like this: