Ticket #2377 (closed defect: wontfix)

Opened 3 years ago

Last modified 10 months ago

We should deactivate plugins when upgrading

Reported by: davidhouse Assigned to: 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 (1.1 kB) - added by davidhouse on 02/02/06 18:21:23.
2377.2.diff (4.6 kB) - added by davidhouse on 02/03/06 17:59:47.
2377.3.diff (4.7 kB) - added by westi on 02/03/06 18:42:53.
a better patch i think

Change History

02/02/06 18:21:23 changed by davidhouse

  • attachment 2377.diff added.

02/02/06 18:23:14 changed by davidhouse

Disclaimer: not actually tested :)

02/02/06 22:20:11 changed by westi

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?

02/03/06 17:59:47 changed by davidhouse

  • attachment 2377.2.diff added.

02/03/06 18:00:55 changed by davidhouse

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.

02/03/06 18:42:14 changed by westi

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.

02/03/06 18:42:53 changed by westi

  • attachment 2377.3.diff added.

a better patch i think

02/03/06 18:43:44 changed by westi

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!

02/03/06 21:01:41 changed by davidhouse

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

02/04/06 11:25:15 changed by westi

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); ?>

02/04/06 14:48:26 changed by davidhouse

Ah. Thanks. :)

02/04/06 14:50:09 changed by davidhouse

  • keywords changed from bg|has-patch to bg|has-patch bg|2nd-opinion.
  • milestone set to 2.1.

Lets get some more opinions on this one.

03/20/06 19:40:11 changed by robmiller

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

08/08/06 04:17:34 changed by _ck_

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.

08/08/06 04:47:01 changed by masquerade

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

08/08/06 04:51:57 changed by masquerade

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

08/25/06 00:27:50 changed by ryan

  • status changed from new to closed.
  • resolution set to wontfix.

07/18/07 22:06:10 changed by Nazgul

  • milestone deleted.

12/14/07 05:00:51 changed by darkdragon

  • keywords changed from bg|has-patch bg|2nd-opinion to bg|has-patch bg|2nd-opinion plugin-management.