Erroneous plugin deactivation should be a manual action

[johnbillion]

"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?

[knutsp]

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.

[SergeyBiryukov]

Related: #25137

[ashfame]

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

[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

[swissspidy]

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.

[johnbillion]

#46564 was marked as a duplicate.

[ckeeney]

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.