Dashboard alert if a plugin/theme was removed from WordPress repo

[sergej.mueller]

If a plugin/theme has been removed for security reasons, WordPress users with an installed plugin must be informed. Ideally as dashboard notification (on update check?). Otherwise the user will never know that the plugin has a security leak.

[SergeyBiryukov]

Related: #29046

[valendesigns]

The hardest part would be deciding on how to tell if the plugin was ever in the repository once it's been removed.

[valendesigns]

This patch requests data from the Plugins API about the active plugins and then save the ones that exist to the found array in the directory_plugins option. When a plugin is removed it will be added to the removed array, in directory_plugins option, so the nag can be displayed. However, it will only show when the plugin is active. Any feedback from the core devs would be much appreciated.

Cheers,
Derek

[dd32]

Worth noting here, that we'd probably add a "removed for x" line to the plugins update-check API response here if we were to go ahead with this.

Realistically, plugins get disabled/removed for a variety of reasons, becoming unlisted in the plugin directory doesn't simply signify security issue / insecure.

[azaozz]

Replying to dd32:

Also that "removed for x reason" should be shown on the Plugins screen, similarly to "update available" notices. Then if it is a security reason, perhaps show on the Dashboard (index.php) and possibly send email to the admin.

Replying to valendesigns:

Looking at 30465.diff: most of this would be handled on the API side. We will only need to add some UI to display these notices. Also debug_backtrace() shouldn't be used in production (as the name suggests). It's very "heavy"/slow.

[nacin]

We need to get a lot better about how we handle plugin removals. Most of the time, it isn't for security. But users are still left in the cold simply because someone has decided to stop wanting to maintain it. I actually dislike this practice, and would rather see it be put into some kind of "abandoned and waiting to be adopted" mode. Perhaps preventing new downloads and notifying users, but not outright closing the page. Once you put it in the directory, you don't really have the option to make it seem like it never existed. Other app stores usually resolve this by allowing people to still access the app's page (and even install it on new devices) as long as you installed it via your account before it was removed.

When it is for security, well, we need to do better at this. But I'm not inclined to change anything in core without first establishing better .org procedures and policies. This is a much larger discussion and doesn't lend itself well to a bug report.

[valendesigns]

Well even if this patch is a wash and never makes it into the core, at the very least it's starting a conversation that needs to take place. The way we handle notifications for outdated plugins, or lack of notifications, needs to change. I agree there are many reasons for a plugin being removed and assuming that its a security reason is not the best approach, but there should be at minimum a set of returned messages for a handful of reasons explaining why the plugin no longer is in the directory i.e. security, user removed, abandoned, etc. that would go a long way to making the UX much better. As well, I would be more than happy to rewrite this patch to use the API and strip out all the extra code that tries to detect plugin removal if we could agree on how the future implementation should work.

@nacin How do we go about making changes to the procedures and policies that govern the Directory? Is this a good first step or do we need to discuss this somewhere else?

[LindsayBSC]

I came here to give a +1 on this as a feature. I know it was marked as "Won't Fix" but ran into a similar issue today on the IRC chat where someone had a plugin installed for 2 years and it was removed from the repo (we assumed because there was a security issue based on it's code) but they never knew it was removed. I understand people really should maintain their own code base HOWEVER since a system is in place for checking for updates from plugins installed from the repo, there could be a system that notifies the user that it no longer exists in the repo.

The way I see it, having a generic message that "this plugin is not longer hosted in the WordPress repo" is better than none. The idea of giving a reason why it was removed is nice, but not as necessary as a simple message.

Again, just giving a +1 to this even though it's mentioned as DNF

[ocean90]

#33350 was marked as a duplicate.

[grapplerulrich]

As the situation has changed over the last four years when @nacin closed this ticket as wontfix would it be a possibility to re-evaluate this?

Now when plugins get pulled from the repo there is reason. For example: ​https://wordpress.org/plugins/no-longer-in-directory/

It would be good to inform users that their plugin is not going to updated and they should look for alternatives.

I would move this from the "Security" component to the "Plugins" component.

[SergeyBiryukov]

#52960 was marked as a duplicate.

[swissspidy]

#56445 was marked as a duplicate.

[joostdevalk]

Reopening this ticket. I think WordPress as a system has a responsibility to tell users whether a plugin is maintained or not. If we know that a plugin has been closed, we should disclose that to the users of that plugin, so they can find an alternative. We've been doing this on WordPress.org for quite a while now, where we only show the reason after 60 days (see ​the code). I think it's time we give that feedback to users in the backend too, and try to reduce the number of sites which have unmaintained / zombie plugins running.

Proposed UI in attachment.

[joostdevalk]

Proposed plugin closed message for the plugins screen.

[SergeyBiryukov]

Replying to joostdevalk:

If we know that a plugin has been closed, we should disclose that to the users of that plugin, so they can find an alternative. We've been doing this on WordPress.org for quite a while now, where we only show the reason after 60 days

Related tickets:

• ​#meta2627 Closed plugins should still have a public page
• ​#meta3356 Plugin Directory: Closed plugins should show WHY closed (with caveat)
• ​#meta4694 Plugin Directory: More user-friendly language regarding plugin closures
• ​#meta5298 Plugin Directory: Show reasons why closed for perma-closures

[masteradhoc]

+1 on this Feature Request. Definately needed to inform Admins in the Pluginoverview that plugins are closed.

Also i would add a last updated date of the plugin could help for plugins that are not getting maintained anymore but are not yet closed

[jonoaldersonwp]

+1

[NekoJonez]

I have two questions here:

1) I'd also port this feature then to themes.
2) Why not link this with Site Health? I use WordFence on various websites to protect my websites and there I got notifications when a plugin is either removed, not updated or has a CVE. So, I'd place it on more places then just the plugin page.

Edit: besides that, giving my +1 here.

[audrasjb]

Moving for 6.4 consideration, with early workflow keyword, since this ticket need a change in the API before working on an actual patch.

[ideag]

Is there a corresponding ticket for the API change already? I'd love to put some work in this.

[ideag]

I've created a quick and dirty PoC for this feature in a form of a plugin. As there is no API, it works by crawling the wp.org pages, which is not sustainable, but it gives a feeling on how it could work. ​https://github.com/ideag/plugin-closure-notifier

[oliversild]

Glad to see this ticket getting some attention! For the reference, here's the talk where I talked about this issue (and linked to this ticket on my slides) at WCEU 2023: ​https://www.youtube.com/live/CkVOyXBP970?feature=share&t=20854

[oliversild]

Yes, it should be ported to themes as well. I think it's a good idea to show this info also on the Site Health where we could even provide a recommendation to the user to find an alternative plugin/theme.

Replying to NekoJonez:

I have two questions here:

1) I'd also port this feature then to themes.
2) Why not link this with Site Health? I use WordFence on various websites to protect my websites and there I got notifications when a plugin is either removed, not updated or has a CVE. So, I'd place it on more places then just the plugin page.

Edit: besides that, giving my +1 here.

[ramon fincken]

Replying to ideag:

Is there a corresponding ticket for the API change already? I'd love to put some work in this.

Added -> ​https://meta.trac.wordpress.org/ticket/7057#ticket

as per https://core.trac.wordpress.org/ticket/58529#comment:1

[NekoJonez]

#58529 was marked as a duplicate.

[NekoJonez]

Since imho this should also count for themes... I changed the title to include that.

[sebastienserre]

This will be definitively a great idea to implement this in Core and a way to fix some security breach introduced by not-maintained plugins or themes

[hellofromTonya]

I'm doing an audit of all tickets marked 6.4 early. What is early?

​The handbook explains the keyword as:

This keyword should only be applied by committers. The keyword signals that the ticket is a priority, and should be handled early in the next release cycle.

early means the commits need to happen during the early part of the Alpha cycle; else, the ticket gets bumped.

Is this ticket an early candidate?

Should it be constrained to only happen during the early part of the 6.4 Alpha cycle, meaning it will get bumped if it isn't completed in time?

I'm thinking no. Once the API work is done, then commits for this ticket could happen up to 6.4 Beta 1. Rather than risk the ticket being bumped if not done in the early phase, I've removed the early keyword. It also helps the 6.4 Release Squad track.

[hellofromTonya]

Replying to audrasjb:

Moving for 6.4 consideration, with early workflow keyword, since this ticket need a change in the API before working on an actual patch.

Is there a meta ticket open for the API work? What's the status of the changes in the API?

[oglekler]

​https://meta.trac.wordpress.org/ticket/7057 - this is the Meta ticket, but there are no movements.

[oglekler]

This ticket is waiting part from Meta side, and we don't have time to make a patch in this Alpha phase, so, I am moving this ticket into the 6.5 milestone.

[NekoJonez]

#60168 was marked as a duplicate.

[ramon fincken]

Slightly related
"Show a warning for plugins in WP admin that haven't received updates in a long time"
https://core.trac.wordpress.org/ticket/49151

[swissspidy]

6.5 Beta is approaching soon and there hasn't been any traction on this in a while and no update an the API side of things. Punting for now so it can be picked up in the next cycle.

[zodiac1978]

Related (or duplicate): #48190

[joostdevalk]

This is all hanging on the plugin API.

Currently, the result to the update API check ( https://api.wordpress.org/plugins/update-check/1.1/ ) would have a plugins key with an array of plugins that have an update, and a no_update key with an array of plugins that do not have an update. I'd suggest adding a closed key and moving plugins that have been closed to there.

Then, for each plugin in that closed array, we could set a reason that could be one of the few types of closures we have, and we should increase the counter on the plugins menu item by one for each.

Trac ticket: https://core.trac.wordpress.org/ticket/30465

This is partially reliant upon https://core.trac.wordpress.org/ticket/53333 / #1332 as the v1.2 updates API will currently return autoupdate data in a different manner. (This is a merge blocker)

[dd32]

Moving to 6.8 for consideration. Pending a lot of work and discussion elsewhere.

I'm fairly not-in-favour of this due to the limited information collected about plugins on WordPress.org when it comes to closure reasons. As noted in comment:7 above, further data may need to be collected / set on the WordPress.org side before this can be considered ready for use.

I'm especially concerned that if this is merged as-is without extra action occuring elsewhere, the text will end up being changed to be overly alertism of "This is DANGEROUS! You need to replace this plugin!11!11" which is a disservice to majority WordPress users and developers.

Work will also needs to be done with the WordPress.org plugin review team to ensure that the reasons cover a wide enough range of cases, to unify the closure reason text between Core and WordPress.org, and to ensure that plugins can be adopted and maintained by others when required. There are a shocking number of plugins closed for mundane reasons (including mundane security issues). Or where the plugin is closed as guideline violation because their email is bouncing, because although the plugin is perfectly working today it's author is unreachable.

As noted, the PR is blocked by #53333 as the 1.2 updates API returns the autoupdate data differently, so this is intentionally blocked until issues are resolved (or someone wants to test and run forward with that ticket too)

[dd32]

Here's an API request to test with.

curl https://api.wordpress.org/plugins/update-check/1.2/ --data 'plugins={"plugins":{"oembed-api/oembed-api.php":{"UpdateURI":"w.org/plugins/oembed-api","Name":"oEmbed+API","Version":"0.1"},"test-plugin-4.php":{"UpdateURI":"w.org/plugins/test-plugin-4","Name":"Test+Plugin+4","Version":"0.1"}}}'

(Note, two closed plugins included, one of which isn't yet 'public')
Results in:

{
  "plugins": [],
  "translations": [],
  "no_update": [],
  "closed": {
    "oembed-api/oembed-api.php": {
      "id": "w.org/plugins/oembed-api",
      "slug": "oembed-api",
      "plugin": "oembed-api/oembed-api.php",
      "url": "https://wordpress.org/plugins/oembed-api/",
      "closed_on": "2015-10-02",
      "closed_reason": "merged-into-core"
    }
  }
}

[oliversild]

Replying to dd32:

I'm especially concerned that if this is merged as-is without extra action occuring elsewhere, the text will end up being changed to be overly alertism of "This is DANGEROUS! You need to replace this plugin!11!11" which is a disservice to majority WordPress users and developers.

I don't think we need to freak people out, but we also can't leave them in the dark. The message could be "Warning: This plugin is currently closed in WordPress.org plugins repository. What does this mean?" - just link that to an article which would then outline all possible reasons why this might be, such as:

• Plugin moved away from WordPress.org and is set to receive updates & support elsewhere.
• Plugin is abandoned, does not receive (security) updates and is not actively developed anymore.
• Plugin is closed due unpatched security issue.
• Plugin in closed due to guideline violation.
• Other.

We should honestly have this marked as priority and roll it out ASAP! This month, in October alone there has been over 400 plugins that have been either temporarily or permanently closed due to a security vulnerability. Additionally, over the past couple of weeks there has been more and more plugins which have decided to switch away from WordPress.org that have hundreds of thousands of active installations and whose users won't be able to receive any (including security) updates via WordPress.org anymore.

We don't need a perfect solution right away. We can always improve. But, the users need to know now!

[palmiak]

@dd32 I think we should try to push it faster than slower. This month we did a cleanup and found over 1000 vulnerabilities in many plugins. Most of them are closed already - ​https://patchstack.com/database/leaderboard.

+1 to push it ASAP with informative descriptions like the ones @oliversild mentioned. We don't want to scare people, but they need to be informed.

[ramon fincken]

Agreed

[masteradhoc]

Agree we should implement a solution that helps users recognize that there is an issue. +1 for the propose or @oliversild

[dd32]

Replying to oliversild:

I don't think we need to freak people out, but we also can't leave them in the dark.

I do agree. But there's work that needs to be done to ensure that it's appropriately communicated, and not a scare-campaign.

The message could be "Warning: This plugin is currently closed in WordPress.org plugins repository. What does this mean?" - just link that to an article which would then outline all possible reasons why this might be, such as:

Yup, all the plugin closure reasons need a plugins handbook page which outlines the reasons and steps forward. Same for plugin rejection reasons. Those handbook pages don't yet exist though.

• Plugin moved away from WordPress.org and is set to receive updates & support elsewhere.

This is one that we're probably never going to be able to publicly acknowledge in any WordPress.org documentation IMHO.

• Plugin is abandoned, does not receive (security) updates and is not actively developed anymore.

This is common, but is not something that is tracked. Specifically, it's either closed as Guideline Violation (Email bounced, or author did not respond to an issue) or a security issue was reported and it was closed for security.

What people see as Guideline Violation basically means everything from Author is a jerk who is deliberately squireling your data away to their servers to Their email hosted on their own VPS was unavailable for 5 minutes.

We don't need a perfect solution right away. We can always improve. But, the users need to know now!

Except, We kind of do. Once such a thing is present within Core, you're opening the floodgates for increased support burdens upon Plugin Authors/Plugin Reviewers, not to mention the support burden for WordPress.org forums, hosting providers, and WordPress providers (think: agencies, etc)

Replying to palmiak:

@dd32 I think we should try to push it faster than slower.

60 days is the WordPress.org plugin directory closure window. If the plugins team (This needs to be discussed with them) wishes to change that, we can.

Given the vast majority of plugin authors appear unable to resolve even the most minor issues with 60/90 days, I doubt increasing that will happen anytime soon.

---

I'm going to try to wrap this PR up into a plugin for testing and try to document the deficiencies in the plugin documentation.

[palmiak]

@dd32
"I'm going to try to wrap this PR up into a plugin for testing and try to document the deficiencies in the plugin documentation."

I think that's the best approach here. It will help us to work on something real and get feedback.

[dd32]

Replying to dd32:

I'm going to try to wrap this PR up into a plugin for testing and try to document the deficiencies in the plugin documentation.

See ​https://github.com/WordPress/wporg-experiments-plugin (Haven't yet submitted it to the plugin repository)

I have converted this to a draft PR for now, and pulled the changes (most of them anyway) into a plugin:

​https://github.com/WordPress/wporg-experiments-plugin

[palmiak]

I tested the current version of the plugin and I just want to say "YES, WE GOT THIS".

Works like a charm.

Now regarding the statuses - IMO they are good but lack explanation on what to do next. But I feel the docs should handle this, and a "learn more" link should be added at the end with the correct.

But at this point already it solves the problem already. Huge thanks @dd32 for handling this.

[chriscct7]

60 days is the WordPress.org plugin directory closure window. If the plugins team (This needs to be discussed with them) wishes to change that, we can.

I definitely think we should not show anything for a plugin inside the WordPress admin within the 60 day closed grace period. The first couple of days after the new WordPress release all-plugin authors email is sent out, hundreds of plugins are temporarily closed for email account issues that take a few days most of the time for their authors to figure out. There are also cases in which large quantities of plugins are temporarily closed and re-opened within a short time period.

[rawrly]

Adding a second recommendation here to encourage no warnings in the wp-admin dashboard if the plugin was recently closed or if the reason is unknown.

This will avoid users being confused or acting out of fear (leading to taking the time to disable or replacing a plugin) for an issue which may receive a patch within a day or two.

I am all for the warnings appearing in the dashboard, this small change will make it safer and less fear inducing for end users who installed a plugin that had a security bug found in it and see such a warning in their panel before the developer could release a patch.