hooks for upgrade and pre_upgrade

[ryanscheuermann]

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...

[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?

[darkdragon]

Draft for opinions on pre and post plugin hooks

[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.

[darkdragon]

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

[darkdragon]

Patch has been tested and is proven to work.

[darkdragon]

Either commit or send to next milestone. Patch works.

[darkdragon]

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

[darkdragon]

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

[darkdragon]

FInishes the enhancement for pre upgrade and post upgrade hooks

[darkdragon]

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

[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.

[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.

[darkdragon]

Candidate for possible inclusion in new plugin data feature.

[jacobsantos]

Core developers do not seem willing to include something like this. It also could create a huge headache for upgrading.