WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 5 months 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:
PR Number:

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 (9)

#1 @knutsp
5 years ago

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.

#3 @ashfame
5 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: @chriscct7
4 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

#5 @johnbillion
4 years ago

  • Type changed from enhancement to feature request

#6 in reply to: ↑ 4 @swissspidy
4 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 @johnbillion
3 years ago

  • Keywords needs-patch added; 2nd-opinion removed
  • Type changed from feature request to enhancement

#10 @johnbillion
7 months ago

#46564 was marked as a duplicate.

#11 @ckeeney
7 months 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.

Note: See TracTickets for help on using tickets.