I have my own SVN repository that has everything checked in from root of the htdocs directory.

The repository includes (I do have some ignores set):

  • Wordpress Core
  • Plugins
  • Themes

My process is:

  • update my repository on a development site first to test
  • commit the changes
  • svn up the production site

My question is:

  • If a plugin installed has database updates attached to the newer version how are those updates applied in my production instance?

I do know that Wordpress core has checks in place to see if the db is updated to the newest version, but I'm unable to find the same information out regarding plugins.

1 Answer 1


This will not be a problem.

WordPress doesn't provide plugins with an explicit update hook for this reason:

If a plugin is manually updated then this upgrade hook won't fire. The best way to manage database upgrades is to do it the same way as WordPress does it. Store an option containing your plugin's database version and check it on the admin_init hook and run the upgrade routine when it doesn't match the version in your plugin. Many popular plugins use this method. It's definitely the most fool-proof.

[From ticket #19681]

So, each plugin has to do its own check to see if its database version is up to date. Plugins will generally run this check each time WordPress runs, or each time the admin panel is accessed, and update their database if needed. So if the plugin has database updates, they will probably be applied the first time someone visits the site after you run svn up. (Or, for some plugins, until someone visits the administration screens.)

  • Wouldn't deactivating and reactivating the updated plugins on the production site after an SVN also do this? I can't find anything saying that they'll probably update after someone hits the site. In 14912 (bottom of the discussion you linked) they mention not doing the every page load thing because of the slowness involved with it. May 26, 2014 at 5:18
  • 1
    @Dez The activation and deactivation hooks are not run by WordPress when a plugin is updated. It was purposely decided not to do this. I don't see the mention of not doing it every page load. That ticket was closed as it was decided that this is the best way to do this (at least for now). I've updated my answer with a quote from #19681 which says that this is the way many popular plugins did it, event way back 2 years ago.
    – J.D.
    May 26, 2014 at 13:46
  • Great, thanks! in the interest of verifying updates & launches go as expected, though, the activate/deactivate method I put out there would also work though for immediate effect, too, right? May 27, 2014 at 14:08
  • @Dez, actually that depends on the type of database updates and how the plugin handles its install code. If the plugin is adding a new table, for example, the table would only be created by de/activating the plugin if it checks for the existence of each table separately on activation. Really, I think the best way to ensure there is an immediate effect is to visit the admin dashboard. De/activating the plugin may have unintended side-affects, and no plugin is expecting that to happen in order for it to update. If the plugin has to be de/activated to update, I'd say that is a plugin bug.
    – J.D.
    May 27, 2014 at 15:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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