Ticket #2927 (new enhancement)

Opened 2 years ago

Last modified 5 months ago

hooks for upgrade and pre_upgrade

Reported by: ryanscheuermann Assigned to: anonymous
Priority: normal Milestone: 2.6
Component: Administration Version: 2.1
Severity: normal Keywords: upgrade plugin-management has-patch commit
Cc:

Description

OK, here's a crazy idea, related to #2377 (deactivate plugins on upgrade)... if we don't deactivate plugins on upgrade, we should have hooks in the upgrade process that would allow a plugin to deactivate/reactivate and even upgrade itself if it needs to.

Or if we keep the deactivate/reactivate on upgrade (in #2377), there should be a hook for "reactivate".

Regardless, I think plugins should have the ability to know when you've upgraded without having to compare the version in the 'init' hook on every page load. Especially if there is a compat problem with the plugin, the plugin could notify you during the upgrade process before you try to hit the site and watch the plugin throw PHP or MySQL errors.

Just the start of an idea, opinions wanted...

Attachments

pre.post.upgrade-hooks.patch (2.1 kB) - added by darkdragon on 12/16/07 06:59:11.
Draft for opinions on pre and post plugin hooks
test1.php (0.6 kB) - added by darkdragon on 12/16/07 07:56:46.
Place in folder called "test-plugin-folder". Use to test patch.
pre.post.upgrade-hooks.complete.patch (6.8 kB) - added by darkdragon on 12/30/07 06:40:05.
FInishes the enhancement for pre upgrade and post upgrade hooks

Change History

07/09/06 14:19:59 changed by darkfate

This would probably have to be built into the plugin though. I'm guessing your talking about like how firefox checks for compat updates whenever it installs an update. The problem is that most plugins don't use RDF or any auto update method. I don't think most plugins call home to see if there is a new version. IMO, it would be better to just disable them all and then have the user notified that they were (On the upgrade page). Then they can just enable them one by one to make sure there isn't any problems. Any other opinions?

12/01/06 03:25:05 changed by matt

  • milestone changed from 2.1 to 2.2.

03/27/07 22:19:27 changed by foolswisdom

  • milestone changed from 2.2 to 2.4.

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

  • keywords changed from upgrade to upgrade plugin-management.

12/16/07 06:59:11 changed by darkdragon

  • attachment pre.post.upgrade-hooks.patch added.

Draft for opinions on pre and post plugin hooks

12/16/07 07:05:57 changed by darkdragon

Added a simple patch that adds this functionality. Basically, I'm content in that it does what the enhancement states. However, I would feel better if there the inclusion was in a sandbox, so that if the plugin dies or errors out, it won't affect the upgrade and will just disable the plugin.

I don't include that logic in this patch, because I feel don't feel that it will be an issue and might add unnecessary overhead. The next patch, will have this functionality base off of the plugin.php sandbox code. I'm not exactly sure how that code might be applied to the current implementation.

Plugin authors have to be made aware that if this patch were to be part of core, they would have to pay attention to how they write their plugins. In that way, the sandbox is almost required.

Oh the patch also assumes that none of patches are evil.

12/16/07 07:11:28 changed by darkdragon

  • keywords changed from upgrade plugin-management to upgrade plugin-management has-patch needs-testing.

12/16/07 07:56:46 changed by darkdragon

  • attachment test1.php added.

Place in folder called "test-plugin-folder". Use to test patch.

12/16/07 07:57:22 changed by darkdragon

  • keywords changed from upgrade plugin-management has-patch needs-testing to upgrade plugin-management has-patch.

Patch has been tested and is proven to work.

12/19/07 01:08:03 changed by darkdragon

  • keywords changed from upgrade plugin-management has-patch to upgrade plugin-management has-patch commit.

Either commit or send to next milestone. Patch works.

12/30/07 05:45:06 changed by darkdragon

  • keywords changed from upgrade plugin-management has-patch commit to upgrade plugin-management has-patch commit dev-feedback.

Still no word on whether this will get into the 2.4 release. Is the patch and problem acceptable?

12/30/07 05:47:27 changed by darkdragon

  • keywords changed from upgrade plugin-management has-patch commit dev-feedback to upgrade plugin-management needs-patch.

Wait. I just realized that the patch needs more work. Continuing the work on the patch.

12/30/07 06:40:05 changed by darkdragon

  • attachment pre.post.upgrade-hooks.complete.patch added.

FInishes the enhancement for pre upgrade and post upgrade hooks

12/30/07 06:41:41 changed by darkdragon

  • keywords changed from upgrade plugin-management needs-patch to upgrade plugin-management has-patch commit.

Hells yeah! I would love if this could get in!

01/03/08 00:56:02 changed by darkdragon

Shown some love to this ticket, can it be reviewed to see if it can be committed.

I added some checking to make sure that the plugin won't bring down the upgrade process if the script failed (haven't tested with a malformed plugin to see if this is the case).

I also added some helper functions to plugins.php in order to simplify the adding of the special hooks.

01/06/08 03:05:47 changed by darkdragon

The problem is not an issue. If a plugin fails, then it will bring down the entire process and nothing will show up nor will the user be able to upgrade.

The @include(PLUGINPATH) prevents an error/warning when including the file if it does not exist for example. It does not prevent errors from halting the main process.

The way the sandbox works for the plugins would be not difficult for the upgrade, but would be slightly pointless. I'm thinking that the same could be applied to make sure that nothing breaks. However, since there is no 'init' hook called in the upgrader, plugins should be able to run. That is if the plugin was written correctly. If it was not then there might be an issue with the plugin calling WordPress functions which don't exist during an upgrade which will bring the upgrader down.

Possible Solution

I was thinking about when the upgrade is started that it would go to a hidden step of running pre upgrade process for each plugin and disabling automatically the plugins which do not play nice. This does fall within the bounds of #2377, which was closed because of breaking many plugins. However, the upgrade process will also get an upgrade which would display which plugins failed during the pre-upgrade process and allow still active plugins that didn't fail to display their status.

The administration plugin's panel will get an extra button for enabling all previously disabled plugins, which will always be saved when the disable all plugins button is checked and during the preupgrade failure. This will allow the user access to enable previously enabled plugins with one click and have them all go through the activation sandbox process.

If none of this is needed, since it would make the upgrade and the patch a lot more difficult to write. If no one is paranoid, I think the first patch combined with elements of the second patch for the plugins.php might be enough to satisfy this ticket.

01/27/08 04:56:13 changed by darkdragon

  • milestone changed from 2.5 to 2.6.

Candidate for possible inclusion in new plugin data feature.