Make WordPress Core

Opened 18 years ago

Closed 16 years ago

#2927 closed enhancement (wontfix)

hooks for upgrade and pre_upgrade

Reported by: ryanscheuermann's profile ryanscheuermann Owned by: jacobsantos's profile jacobsantos
Milestone: Priority: normal
Severity: normal Version: 2.1
Component: Administration Keywords:
Focuses: Cc:


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 (3) (2.1 KB) - added by darkdragon 16 years ago.
Draft for opinions on pre and post plugin hooks
test1.php (590 bytes) - added by darkdragon 16 years ago.
Place in folder called "test-plugin-folder". Use to test patch. (6.8 KB) - added by darkdragon 16 years ago.
FInishes the enhancement for pre upgrade and post upgrade hooks

Download all attachments as: .zip

Change History (22)

#1 @darkfate
18 years ago

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?

#2 @matt
17 years ago

  • Milestone changed from 2.1 to 2.2

#3 @foolswisdom
17 years ago

  • Milestone changed from 2.2 to 2.4

#4 @darkdragon
16 years ago

  • Keywords plugin-management added

16 years ago

Draft for opinions on pre and post plugin hooks

#5 @darkdragon
16 years ago

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.

#6 @darkdragon
16 years ago

  • Keywords has-patch needs-testing added

16 years ago

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

#7 @darkdragon
16 years ago

  • Keywords needs-testing removed

Patch has been tested and is proven to work.

#8 @darkdragon
16 years ago

  • Keywords commit added

Either commit or send to next milestone. Patch works.

#9 @darkdragon
16 years ago

  • Keywords dev-feedback added

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

#10 @darkdragon
16 years ago

  • Keywords needs-patch added; has-patch commit dev-feedback removed

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

16 years ago

FInishes the enhancement for pre upgrade and post upgrade hooks

#11 @darkdragon
16 years ago

  • Keywords has-patch commit added; needs-patch removed

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

#12 @darkdragon
16 years ago

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.

#13 @darkdragon
16 years ago

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.

#14 @darkdragon
16 years ago

  • Milestone changed from 2.5 to 2.6

Candidate for possible inclusion in new plugin data feature.

#15 @jacobsantos
16 years ago

  • Owner changed from anonymous to jacobsantos

#16 @santosj
16 years ago

  • Keywords needs-patch added; has-patch commit removed

#17 @jacobsantos
16 years ago

  • Keywords upgrade plugin-management needs-patch removed
  • Milestone 2.9 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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

#18 @jacobsantos
16 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

#19 @jacobsantos
16 years ago

  • Resolution set to wontfix
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.