Opened 9 years ago
Last modified 5 years ago
#36705 new defect (bug)
Read-only plugins are uninstalled before deletion fails
Reported by: | andy | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.5.1 |
Component: | Plugins | Keywords: | |
Focuses: | administration | Cc: |
Description
Plugin uninstall happens before deletion is attempted. If the plugin's files are read-only, the plugins list action says "Delete" but all that happens is uninstall and an error.
Plugins that cannot be deleted because they are read-only in the filesystem should not have Delete buttons. is_writable()
should be checked while constructing the actions. If read-only, either remove the button or replace it with an action which deletes the plugin's data and leaves the files. I prefer the latter.
Note: See
TracTickets for help on using
tickets.
Don't think removing the button would be a good option because a user might not understand why there is no delete button, so I think there should be some user feedback in such a scenario.
But wondering if there are other similar situations in WordPress where functionality is disabled due to some configuration and how that then is displayed? This should probably work kind of similar I think.
I also understand the scenario to be able to remove the data even if you are not able to delete the plugin but I wonder how common scenario that is? If you don't want to use the plugin but can't delete it you would keep it deactivated and from a user perspective it shouldn't interfere with anything right? And resetting a plugins data so it would be as initially installed seems like kind of a different and bigger feature.