Opened 9 years ago
Last modified 3 months ago
#30465 reopened feature request
Dashboard alert if a plugin/theme was removed from WordPress repo
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | 6.5 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Security | Keywords: | dev-feedback needs-patch security |
Focuses: | Cc: |
Description
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.
Attachments (2)
Change History (38)
#3
@
9 years ago
The hardest part would be deciding on how to tell if the plugin was ever in the repository once it's been removed.
#4
@
9 years ago
- Keywords has-patch dev-feedback added
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
#5
follow-up:
↓ 6
@
9 years ago
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.
#6
in reply to:
↑ 5
@
9 years ago
- Milestone changed from Awaiting Review to Future Release
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.
#7
@
9 years ago
- Milestone Future Release deleted
- Resolution set to wontfix
- Status changed from new to closed
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.
#8
@
9 years ago
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?
#9
@
9 years ago
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
#11
@
5 years ago
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.
This ticket was mentioned in Slack in #core-committers by ocean90. View the logs.
4 years ago
#15
follow-up:
↓ 16
@
9 months ago
- Resolution wontfix deleted
- Status changed from closed to reopened
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.
#16
in reply to:
↑ 15
@
9 months ago
- Keywords needs-patch added; has-patch removed
- Milestone set to 6.3
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
This ticket was mentioned in Slack in #core by oglekler. View the logs.
6 months ago
#18
@
6 months ago
+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
This ticket was mentioned in Slack in #feature-notifications by tn-edith. View the logs.
6 months ago
This ticket was mentioned in Slack in #core by nekojonez. View the logs.
6 months ago
#22
follow-up:
↓ 27
@
6 months ago
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.
#23
follow-up:
↓ 33
@
6 months ago
- Keywords early added
- Milestone changed from 6.3 to 6.4
Moving for 6.4
consideration, with early
workflow keyword, since this ticket need a change in the API before working on an actual patch.
#24
follow-up:
↓ 28
@
6 months ago
Is there a corresponding ticket for the API change already? I'd love to put some work in this.
#25
@
6 months ago
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
#26
@
6 months ago
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
#27
in reply to:
↑ 22
@
6 months ago
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.
#28
in reply to:
↑ 24
@
6 months ago
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
#30
@
6 months ago
- Summary changed from Dashboard alert if a plugin was removed from WordPress plugins repo to Dashboard alert if a plugin/theme was removed from WordPress repo
Since imho this should also count for themes... I changed the title to include that.
#31
@
4 months ago
- Keywords security added
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
#32
@
4 months ago
- Keywords early removed
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.
#33
in reply to:
↑ 23
@
4 months ago
Replying to audrasjb:
Moving for
6.4
consideration, withearly
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?
#34
@
3 months ago
https://meta.trac.wordpress.org/ticket/7057 - this is the Meta ticket, but there are no movements.
Related: #29046