Plugin activation hooks no longer fire for updates
Following up on @scribu‘s post with further rationale and the 31compat tag.
The many problems. When plugin upgrades were introduced in 2.8, the activation hook fired for them. The deactivation hook did not. This was inconsistency number one.
When bulk plugin upgrades were introduced on the Tools > Updates screen in 2.9, the activation hook did not fire (during the bulk upgrade). This was inconsistency number two.
Bulk plugin upgrades were given greater prominence in 3.0, with the Updates move to under Dashboard, and a new bulk action on the plugins screen. This made the second inconsistency far more prominent.
Additionally, activation hooks could always fire on activation, because that has to be done through the admin, but updates don’t. Updates done manually (including SVN) was just one more instance where we may not have been firing updates. This was inconsistency number three.
We felt that the proper fix was to prevent the activation hook from firing on any upgrades, bulk or not, as this was not intuitive. Sorry if your plugin relied on this undocumented behavior.
The theory behind the right way to do this. The proper way to handle an upgrade path is to only run an upgrade procedure when you need to. Ideally, you would store a “version” in your plugin’s database option, and then a version in the code. If they do not match, you would fire your upgrade procedure, and then set the database option to equal the version in the code. This is how many plugins handle upgrades, and this is how core works as well.
The right way to do this. I would do what many other plugins do and do the upgrade procedure as I described, and as Peter and Andy described in the previous post.
Further reading. You can read more about this issue, on ticket #14915.
Michael Torbert 10:18 pm on October 27, 2010 Permalink
Even though that’s certainly a way to accomplish the same thing, the logical solution would be to make another hook for activation.
Ryan Boren 10:20 pm on October 27, 2010 Permalink
Which would not run for manually upgraded plugins. Hooks for upgrades is a non-starter. Plugins have to do it.
Michael Torbert 10:25 pm on October 27, 2010 Permalink
I would guess that most plugins are automatically upgraded, making this a simple solution.
Ryan Boren 10:29 pm on October 27, 2010 Permalink
Many people use git or svn, and relying on a hook is not multisite compatible.
Stephen Cronin 1:55 pm on October 28, 2010 Permalink
Thanks for explaining that Nacin.
I’m currently misusing the activation hook – my activation function includes all the update logic I need. I’m aware it doesn’t work for FTP updates, so my update instructions tell people to deactivate and then reactivate the plugin. Of course, that won’t work for SVN updates, which I hadn’t considered (although with due respect to Ryan, I’d argue that not many *average users* would update via SVN).
If the logic needs to be handled via the plugins, that’s fine, I’ll update mine. In fac,t I used to handle it in the plugin but removed it because I figured that running something just on activation would be more efficient that checking the version number on every single page load. For one plugin, not much of a drama, but when you start having 30 plugins all checking their version number on every page load of the site… But if that’s what we have to do, then that’s what we have to do.
Andy Skelton 2:16 pm on October 28, 2010 Permalink
It’s not inefficient for every plugin to store a small amount of data in the options table. They will all be automatically loaded with a single query. The overhead added by a single, small row is small enough to ignore.
Peter Westwood 2:19 pm on October 28, 2010 Permalink
Agreed.
Also – you should try really hard to ensure your plugin still works even with the old settings until the upgrade had happened unless it can be done without user interaction.
In most cases if you need user interaction you can trigger an admin_notice on the next page load after the update.
If you have a update that takes a while consider using a wp-cron “job” to do the migration work.
Stephen Cronin 2:47 pm on October 28, 2010 Permalink
Thanks for pointing that Andy.
I was assuming a separate DB call for each plugin’s options entry. I knew the core options were bundled into a single DB call, but was under the impression (from heresay, not anything resembling facts) that non core options weren’t included and needed a separate DB call.
And Peter, yes, you’re right of course, the plugin shouldn’t rely on something existing that may not be there. I code properly *most* of the time, but I guess I’ve leant on the activation hook crutch occasionally. I think I need to spend some time with my plugins and make sure I’m not making the problem I’m complaining about
Peter Westwood 2:49 pm on October 28, 2010 Permalink
@Stephen: As long as you ask for your option to be autoloaded when registered it comes in one query with the rest of the autoloads
demetris 11:48 am on October 29, 2010 Permalink
Just a note regarding autoloading of options:
By default, autoload is set to yes for all options added via add_option. So, other than adding your option, there is nothing you need to specify if you want it to be autoloaded.
More here: http://codex.wordpress.org/Function_Reference/add_option
Jarkko Laine 7:35 pm on April 12, 2011 Permalink
Hi, just a quick note to point out that this documentation page is still giving wrong instructions for plugin developers: http://codex.wordpress.org/Creating_Tables_with_Plugins
Cheers,
Jarkko
Clint 2:54 am on May 15, 2012 Permalink
I am VERY late to this party, but when I manually de-activate a plugin, and then reactivate it again manually, won’t fire the “acivation hook”? Seems a little stupid. Also makes testing my plugin a huge pain.
Andrew Nacin 8:40 pm on August 31, 2012 Permalink
Even later to reply to you — If you manually de-activate and manually reactivate, yes, it fires the activation (and deactivation) hooks. This was only for core’s one-click updates — when we update a plugin, we do not fire an activation hook.