We recently discovered an issue in our commercial plugins related to a change in the WordPress API. It turns out that since WordPress 3.1 was released the register_activation_hook() function is no longer called during a plugin upgrade! This is a significant change in behavior from previous versions that called the WordPress activation hook on every update. This has caused numerous problems and forced Cyber Sprocket to come up with a patch in our own wpCSL framework.
Why Is This A Problem?
Any site running a version of WordPress older than 3.1 would automatically get any feature and supporting application tweaks whenever they upgraded the plugin. Most plugin authors, Cyber Sprocket included, would use the register_activation_hook API call to make sure the user had the latest database structure, settings, and other elements that keep the plugin working. For example, with Store Locator Plus 3.0 this hook would ensure that the user’s Google Maps API v2.0 settings were converted to the Google Maps API v3.0 equivalent.
As of WordPress 3.1 the function that does this conversion is not called. To make matters worse, it is not called only in certain circumstances. For example:
- User installs upgrade via a downloaded zip file: updates called.
- User does auto-update on a deactivated plugin then activates the plugin: updates called.
- User does auto-update on an activated plugin: updates NOT called.
As you can see this is inconsistent. Even worse, plugins that worked find up to version 3.1 now have the potential to suddenly break.
Cyber Sprocket has created a new version of our wpCSL framework that we use to build WordPress plugins. The update uses standard admin panel interfaces to call our own “plugin has changed” hooks. The short version of how this works is as follows:
- User is on the admin panel…
- The plugin is active…
- Check the version of the plugin as stored in the options table of WordPress…
- Is it different than the current version of our plugin?
- Yes, run the upgrade callback function if it is set.
- Update the plugin version stored in the options table to the current installed version.
That’s it. A fairly simple solution, but more things we need to manage in our plugin framework because the WordPress development team changed things.