[wp-trac] [WordPress Trac] #14912: Introduce register_upgrade_hook()

[WordPress Trac]

#14912: Introduce register_upgrade_hook()
-----------------------------+----------------------------------------------
 Reporter:  scribu           |       Owner:                
     Type:  enhancement      |      Status:  new           
 Priority:  normal           |   Milestone:  Future Release
Component:  Upgrade/Install  |     Version:                
 Severity:  normal           |    Keywords:  has-patch     
-----------------------------+----------------------------------------------
Changes (by batmoo):

 * cc: batmoo@… (added)


Comment:

 This is awesome guys!

 Replying to [comment:23 scribu]:
 > I've added an is_admin() at the beginning, to keep the front-end light
 and free of potential weirdness.

 The one potential problem with only firing the update hook on is_admin is
 that the front-end is going to have updated plugin code which likely
 expects updated data, and that's more likely to cause weirdness.

 For example, if I go from 0.1 to 0.2 and my update hook changes the name
 of an option from 'my_option' to 'myplugin_my_option', my code is going to
 reference the option as 'myplugin_my_option'. If a user visits my site
 before the update hook fires, my plugin is probably not going to work. But
 then again, this might just be a coding practice issue.

 And from the looks of it, the current patch fires
 update_option/update_site_option on every page load for all update hooks
 registered. It might be better be to fire those only if the version is
 different.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/14912#comment:25>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software