WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've researched this a few times, yet my searching does not reveal much except custom code which may or may not be good WordPress practice.

As of the latest releases (WordPress 3.9 "Smith"), has a hook been added to the plugin update process? I'm asking because its a very basic need, yet I do not see it added to the codex (yet). If not, what is the common and best practice developers employ?

EDIT: Just to clarify, I'm not talking about activation, but about updating, that way, if there are changes in database or otherwise it can be addressed.

share|improve this question
duplicate of wordpress.stackexchange.com/questions/61456/… – drzaus Sep 9 '14 at 9:03
up vote 7 down vote accepted

I don't think an action has been added. You can look at version details for any version and see any new actions added.

The WordPress Way to run code on plugin update is what is described here:

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.

and with code example here:

function myplugin_update_db_check() {
    global $jal_db_version;
    if (get_site_option( 'jal_db_version' ) != $jal_db_version) {
add_action( 'plugins_loaded', 'myplugin_update_db_check' );
share|improve this answer
Thank you - I'll simply use that method then. WP really has to add an action for this :D – user1915665 May 20 '14 at 2:20
technically you're supposed to use register_activation_hook, since in most cases a plugin gets deactivated/activated whenever you update it from the admin. Hooking to plugins_loaded will do your check on every page load (including frontend). There was talk about introducing register_update_hook, but it was marked as WONTFIX a while ago. The discussion there is helpful. – drzaus Sep 9 '14 at 9:10
It's important to understand that a mass plugin update does NOT run activation hooks - it SHOULD, but doesn't at 3.9.2. By "mass update" I mean an update done from the Dashboard update page. Individual updates done from within the plugin page run the hooks just fine. – Brian C Sep 21 '14 at 0:26
The thing is plugins can also be updated via FTP which means that the hook will not be fired in any case. That's why you need to resort to the option stored in the database. – giraff Sep 1 '15 at 16:37
To expand on @giraff's comment, the same is true for people who manage their code with source control like SVN or Git. Because of that, this answer is the best way to handle upgrades. – doublesharp Sep 10 '15 at 16:53

From the discussion where they decided not to add a custom hook/function specific to upgrade, it sounds like "most people" (as of 4 years ago) use register_activation_hook, since it's called when a plugin is upgraded through the admin page; most examples I've seen since then follow that trend.

For most usage I would suggest not hooking through plugins_loaded, as it would get called on every page load. The exception to this is mentioned in the discussion: upgrade paths via FTP/SVN are 'edge cases', since WP wouldn't have a mechanism to know that the plugin was changed, in which case the previous answer might be more relevant.

See https://gist.github.com/zaus/c08288c68b7f487193d1 for a 'simple framework' example using register_activation_hook.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.