Opened 11 years ago
Last modified 4 weeks ago
#27994 new enhancement
Erroneous plugin deactivation should be a manual action
Reported by: | johnbillion | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 2.5 |
Component: | Plugins | Keywords: | needs-patch bulk-reopened |
Focuses: | administration | Cc: |
Description
"The plugin foo.php
has been deactivated due to an error: Plugin file does not exist."
This seemingly harmless behaviour on the Plugins screen can end up being a royal pain for developers. Consider the scenario where you've renamed your plugins directory or any of the plugins within it (ie. to do some debugging with plugins disabled), and then you visit the Plugins screen. BAM, your plugins have been deactivated.
I think this behaviour should be removed, and instead a list of erroneous plugins displayed, with the option to manually deactivate them.
Thoughts?
Change History (10)
#3
@
11 years ago
+1 I work with different GIT branches having new plugins in them and if I happen to visit plugins page, the plugin from another branch is deactivated because it doesn't exist in other branches and I would have to come back and activate the plugin again when I switch back to that branch.
#4
follow-up:
↓ 6
@
9 years ago
- Keywords close added
- Priority changed from low to normal
I think a lot of normal users use this behavior in a positive way to force deactivate plugins that are causing whitescreens. Personally, I think close as wontfix
#6
in reply to:
↑ 4
@
9 years ago
- Keywords close removed
Replying to chriscct7:
I think a lot of normal users use this behavior in a positive way to force deactivate plugins that are causing whitescreens. Personally, I think close as wontfix
When a plugin file does not exist anymore, there's no harm in leaving it activated. There's no file that could be loaded.
Something along the lines of "There was an error with the plugin foo.php: Plugin file does not exist. [Delete plugin]" would make for a simple but useful addition.
#7
@
8 years ago
- Keywords needs-patch added; 2nd-opinion removed
- Type changed from feature request to enhancement
#11
@
6 years ago
- Keywords bulk-reopened added
I agree we need the ability to disable this behavior, preferably in wp-config.php
. It is possible there are multiple instances of WordPress running connected to a single database that may not be configured identically. Here is my use-case I posted on #46564 (duplicate issue)
I have a production instance of WordPress running that relies on https://wordpress.org/plugins/wp-stateless/ to store media on Google Cloud Storage.
I plan to migrate to Google App Engine and when I do so I won't need WP-Stateless anymore (because I can mount GCS buckets into an app engine instance).
The simple solution is to get a new instance of WP running connected to the production database without WP-Stateless and then point DNS at the new instance. This works, but if an admin user on the new instance merely visits the WP Plugins page, the new instance will disable wp-stateless in the database and break the production instance before the DNS has migrated over.
I know this example is very specific and maybe even contrived, but I think users expect that they can safely browse the plugins page without breaking anything and today that isn't necessarily the case.
#12
@
4 weeks ago
Right now I got a project for optimization and found out that I cannot enter the admin due to a fatal error. Luckily, the frontend is working. I got the project database and launched the site locally. But the code in the repository has no plugins, and as a result, I got several messages that plugins were deactivated and all this information was removed from the database. I will get the full project backup from the system administrator, but this situation is very inconvenient when you had a plugin, and it was accidentally deleted from the filesystem, for example, and now you have no idea what it was if you didn't save the error message. In my case, I have the database and will get the backup, but all this automatic removal is very inconvenient.
I also think that WP should store the version of the plugin that was installed, and in case that plugin is missing, offer to reinstall the same version. Possibly this should be another ticket for this enhansment.
With the option to bulk activate plugins, I don't see any problems. I never ever rename the plugins folder except when wanting to deactivate all plugins when WordPress fails.
Keeping plugins "activated" when they don't even exist, as WordPress sees it, could be a problem for end users, or at least bad for performance.
If this was to be implemented I would suggest the behaviour only happens when WP_DEBUG.