Ticket #2377 (closed defect (bug): wontfix)

Opened 6 years ago

Last modified 4 years ago

We should deactivate plugins when upgrading

Reported by: davidhouse Owned by: anonymous
Priority: normal Milestone:
Component: Administration Version: 2.0
Severity: normal Keywords: bg|has-patch bg|2nd-opinion plugin-management
Cc:

Description

As this breaks a lot of upgrades.

Attachments

2377.diff Download (1.1 KB) - added by davidhouse 6 years ago.
2377.2.diff Download (4.6 KB) - added by davidhouse 6 years ago.
2377.3.diff Download (4.7 KB) - added by westi 6 years ago.
a better patch i think

Change History

Disclaimer: not actually tested :)

I'm not a fan of this patch as it stands.

I am not a complete fan of deactivating all plugins on upgrade either but we should at least store the list of active plugins and provide a way of reactivating them easily.

Maybe a button should appear on the plugins page which allows you to reactivate your plugins - either all at one or one at a time for easy testing?

Maybe the saved array of plugins could be used to highlight within the plugins page using an alternate colour which plugins were active before upgrade?

I've attached a new patch which replaces the old one and adds these new features:

  • Deactivated plugins are stored in an option, deactivated_plugins and are greyed out on the plugins page with 'deactivated in upgrade' displayed after their name. The button is also labelled 'Reactivate' instead of 'Activate'.
  • Plugins deactivated are shown on the successful upgrade completed screen.

This patch is nice.

Had a few issues with it when I tested on my trunk test install which i think I have fixed in the attached patch.

westi6 years ago

a better patch i think

The only known issue with this patch at present is that if you upgrade twice you lose you deactivated list which is a bit mean!

Is it just me or is your patch exactly the same as mine, westi? What exactly did you change?

I just did a diff of the two diffs and yes they are very similar.

I fixed the display in upgrade.php of the list of plugins disabled. (I thought I changed more than that one line ;-))

$plugin_data = get_plugins_data($plugin); ?> became: $plugin_data = get_plugin_data(ABSPATH."wp-content/plugins/".$plugin); ?>

Ah. Thanks. :)

  • Keywords bg|2nd-opinion added
  • Milestone set to 2.1

Lets get some more opinions on this one.

+1, works well and is much better than not deactivating at all.

Actually the user should be strongly cautioned and given a link to click to deactivate all plugins but it should NEVER be done automatically for them.

Some plugins purge their db tables upon deactivation/activation and that behavior can cause data loss without their consent or knowledge.

We deactivated plugins on upgrade in the past, and had complaints of breakage from plugins being deactivated and the fact that the upgrade script is available to the world, so anyone could come along and disable all the plugins breaking the site. This was fixed long ago, see #1165

Not to mention, now we have activate/deactivate hooks, and deactivating all would have to call all the deactivation hooks, which could potentially cause undesired side-effects with plugins that clean up after themselves upon deactivation, assuming a user is going to uninstall, or even plugins that take advantage of the deactivation hooks to query whether or not data should be deleted and die out before the page can finish loading and completely deactivate the plugin (I'm not sure how many other people do this, but I know I do in at least one unreleased plugin).

So, definitely a -1

  • Status changed from new to closed
  • Resolution set to wontfix
  • Milestone 2.1 deleted
  • Keywords plugin-management added
Note: See TracTickets for help on using tickets.