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:
Acts7, 
MadtownLems, and 19 others are discussing. 
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.