Make WordPress Core

Opened 9 years ago

Closed 9 years ago

Last modified 7 years ago

#2377 closed defect (bug) (wontfix)

We should deactivate plugins when upgrading

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


As this breaks a lot of upgrades.

Attachments (3)

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

Download all attachments as: .zip

Change History (19)

@davidhouse9 years ago

comment:1 @davidhouse9 years ago

Disclaimer: not actually tested :)

comment:2 @westi9 years ago

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?

@davidhouse9 years ago

comment:3 @davidhouse9 years ago

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.

comment:4 @westi9 years ago

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.

@westi9 years ago

a better patch i think

comment:5 @westi9 years ago

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!

comment:6 @davidhouse9 years ago

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

comment:7 @westi9 years ago

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); ?>
$plugin_data = get_plugin_data(ABSPATH."wp-content/plugins/".$plugin); ?>

comment:8 @davidhouse9 years ago

Ah. Thanks. :)

comment:9 @davidhouse9 years ago

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

Lets get some more opinions on this one.

comment:10 @robmiller9 years ago

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

comment:11 @_ck_9 years ago

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.

comment:12 @masquerade9 years ago

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

comment:13 @masquerade9 years ago

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

comment:14 @ryan9 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

comment:15 @Nazgul8 years ago

  • Milestone 2.1 deleted

comment:16 @darkdragon7 years ago

  • Keywords plugin-management added
Note: See TracTickets for help on using tickets.