Plugin activation hooks
Attention all plugin authors:
If you were using register_activation_hook() to also handle updates from older versions of your plugins, you will not be able to do so any more in WP 3.1: [16012]
The activation hook is now fired only when the user activates the plugin and not when an automatic plugin update occurs. This is consistent with how the deactivation hook works.
There is a proposal for a register_update_hook() instead: #14912
Also, the callbacks for de/activation can now accept a network activation flag:
demetris 2:55 pm on October 27, 2010 Permalink
Argh! I do not like this!
I don’t have a good grasp of the issue, but I somehow feel we shouldn’t remove this feature, even with its current inconsistent behaviour, without having something to replace it first.
Why not wait until we have an update hook?
scribu 3:24 pm on October 27, 2010 Permalink
It’s not a feature, it’s a an inconsistency that leads to obscure bugs.
As for the update hook, please lobby for it’s inclusion then.
Peter Westwood 3:29 pm on October 27, 2010 Permalink
It is a bug pure and simple and this fixes it.
Rich Pedley 3:48 pm on October 27, 2010 Permalink
argh. darn dagnabit. better change my update routine then. I’m so relieved I did some changes in preparation for this, it’s going to catch a lot of plugin authors out though.
Rich Pedley 3:51 pm on October 27, 2010 Permalink
actually quick query, what is the best thing to hook onto for updates at the moment? init?
Peter Westwood 3:52 pm on October 27, 2010 Permalink
That is what they get for holding it wrong.
Relying on a hook for update detection is not a good ideatm as there are too many scenarios in which is won’t fire.
Good plugins would use something similar to the
$db_versionthat core uses itself.Andy Skelton 3:58 pm on October 27, 2010 Permalink
For ages I have used a constant and bumped it only when the updated plugin will need to run some upgrade code. I agree this is the way to go.
demetris 4:52 pm on October 27, 2010 Permalink
“Good plugins would use something similar to the $db_version that core uses itself.”
I would agree if you said “Perfect plugins”, because I know of good plugins that rely on this inconsistently fired hook to run their upgrade code.
I think the problem I see with this change is that we remove something people use without telling why it is removed and what should be used instead.
If an update hook can never be reliable (because plugins are often updated through channels of which WP cannot be aware), then we should wontfix that ticket and tell people clearly that the only reliable method is what you and Andy describe.
scribu 5:11 pm on October 27, 2010 Permalink
We announced it here and described the reasons for it.
We also suggested a fix.
The register_update_hook() proposed is exactly what westi and Andy describe, so it is reliable.
In conclusion, please check your facts first.
demetris 6:23 pm on October 27, 2010 Permalink
@scribu:
If I understand correctly, the feature is removed because it cannot be relied upon: the hook is fired in some cases, but not in others. This announcement says nothing of the sort.
The fix suggested is slated for a future release (and we are now into feature freeze). What are people to use for 3.1?
About the way register_update_hook works, my apologies. I had not looked at the code and, going by the function’s name, I thought it was a hook. But it is not a hook. It is not hooked on to anything. It is a helper function that, as you said, does what Peter and Andy described and that runs everytime the admin is loaded.
(Which does not provide for all scenarios: If I don’t update via the admin, the update code will not run until I visit the admin.)
scribu 6:32 pm on October 27, 2010 Permalink
To clarify, the activation hook can’t be relied upon for updating. Makes sense?
Furthermore, it’s not removed, just restricted to it’s intended purpose.
Also, we still have a few days until feature freeze, so I’m hopeful.
Anyway, register_update_hook() doesn’t require any other core modifications, so plugin authors can just drop it in their plugin, wrapped in an
if ( !functions_exists() )demetris 6:55 pm on October 27, 2010 Permalink
According to the schedule, feature freeze was on the 15th of October:
http://wpdevel.wordpress.com/version-3-1-project-schedule/
In any case, I think an extra post explaining all this would be useful:
A.
We don’t fire the activation hook anymore on plugin updates because it was not reliable for update detection:
1. It did not work for bulk updates
2. It did not work for network updates
3. It did not help for updates not done via the admin
B.
The reliable method for update detection is [what Peter and Andy described].
C.
[What we say here depends on whether register_update_hook makes it into 3.1.]
scribu 7:45 pm on October 27, 2010 Permalink
I meant to say primary code freeze.
Anyway, nice summary.
Alex M. 8:51 pm on October 27, 2010 Permalink
+1 to using a constant/variable. I’ve always stored a version number in my settings array and when I loaded the settings, I checked the version and did an upgrade if need be.
Relying on a hook is poor form in general.
Plugin activation hooks no longer fire for updates « WordPress Development Updates 10:16 pm on October 27, 2010 Permalink
[...] Comments Alex M. on Plugin activation hooksscribu on Plugin activation hooksdemetris on Plugin activation hooksscribu on Plugin [...]
Will Anderson 11:31 pm on October 27, 2010 Permalink
I’m thinking this should be a simple s/register_activation_hook/register_update_hook for 99% of plugins that will be broken, assuming register_update_hook makes it into 3.1
scribu 8:38 pm on October 28, 2010 Permalink
Yeah, the only thing would be that register_update_hook() requires a version too.
Jeff 4:46 am on October 28, 2010 Permalink
Reading this and Nacin’s post really helped clarify this. It does make sense to not expect activation hooks to handle upgrades. Especially if a plugin is not deactivated on upgrade (svn, ftp etc).
Excuse me while I go make updates.
arena 12:28 pm on October 28, 2010 Permalink
Is there a way to avoid an automatic plugin update ?
scribu 8:39 pm on October 28, 2010 Permalink
Yes. There’s a plugin called something like “No Plugin Updates” that does this. You should check it out.
Cian Kinsella 4:21 pm on February 28, 2011 Permalink
This really did catch us out, I’m sure we won’t be the last. Shouldn’t the automatic update process stop displaying misleading messages such as “Deactivating the plugin…, Removing the old version of the plugin…, Plugin updated successfully, Reactivating the plugin…
scribu 4:32 pm on February 28, 2011 Permalink
It doesn’t say “Successfully fired activation hook”, so it’s not misleading.
Cian Kinsella 5:33 pm on February 28, 2011 Permalink
You are pulling my leg aren’t you?
scribu 5:39 pm on February 28, 2011 Permalink
Only partly. Read the discussion again (including the one on trac).
face-gamers.com 10:43 am on March 8, 2011 Permalink
We lost all of our comments by updating the plugin.
How can we stop this happening in the future apart from not updating?
scribu 2:58 pm on March 8, 2011 Permalink
This is not the best place to ask. Please use the support forums: http://wordpress.org/support/ (remember to actually mention the plugin name).
Steve 3:19 am on October 25, 2011 Permalink
Hello,
Had a question about testing my changes to my plugin’s upgrade routine once I’m done making those changes.
I don’t want to push an update (the next higher svn tag) to my plugin’s SVN repo on WordPress just to test how an automatic update would behave. Do I simply just downgrade my live wordpress to the lower version of my plugin and then with filezilla ftp , just copy over the newer version of my plugin ?
thanks for the info above
Steve
Steve 1:41 pm on October 25, 2011 Permalink
You can ignore that. The obvious solution to testing the auto upgrade (without pushing a newer version that I didn’t want wp users to download) is to simply install a version going back to two versions to my WordPress blog, and then I can test what the auto update does after tweaking my current version a little.
Mika "Ipstenu" Epstein 1:07 pm on October 25, 2011 Permalink
Steve – That’s not really a question for this post
You could either post in the support forums: http://wordpress.org/support/ or email the hackers list: http://lists.automattic.com/mailman/listinfo/wp-hackers
But basically if you wanted to test an upgrade, and knowing that the activation hook is called “when the user activates the plugin and not when an automatic plugin update occurs” then you really don’t even need to downgrade. I would upload the plugin as trunk and NOT make it the release version, then download the ‘development’ version from http://wordpress.org/extend/plugins/YOURPLUGIN/download/ and use the zip-uploader in WP to upgrade it.
If you need more help on doing that, post on the forums or mail hackers, please