Plugin Upgrade Strategy

Reading register_activation_hook() told me that in wordpress 3.1, this will only work for every plugin activation, not plugin upgrade.

What I want to know is, what’s the best plugin upgrade strategy?

Read More

My though is:

  1. on action ‘admin_init’ check for ‘{plugin_name}_version’ option
    1. if ‘{plugin_name}_version’ doesn’t exist, let’s assume it’s from previous version (because at that version, we don’t have ‘{plugin_name}_version’ option, yet. Go to process 2.
    2. if ‘{plugin_name}_version’ option exists and doesn’t match with ‘{plugin_name}_version’ set in script, go to process 2.
    3. if ‘{plugin_name}_version’ option match with ‘{plugin_name}_version’ set in script, exit process.
  2. launch our plugin upgrade function with ‘{plugin_name}_version’ value as parameter
  3. do whatever needed for this upgrade process
  4. after upgrade process finished, set ‘{plugin_name}_version’ option to ‘{plugin_name}_version’ from script.

Any comment for this process?

Related posts

Leave a Reply

1 comment

  1. This was recently discussed at length on the wp-hackers list. Here’s the thread:

    Quoting Otto from the list:

    The simplest method that would work
    everywhere would be simply to store
    the version number of the plugin
    somewhere (like in your options entry
    in the database), then compare the
    stored version with your known
    current and hardcoded version. When
    you detect the difference, then that
    means an upgrade has taken place, and
    you can act accordingly. Another way
    is simply to make the plugin detect
    outdated options or older schemas and
    upgrade them on-the-fly. This is
    probably the most reliable, but it
    does depend on what exactly you’re
    upgrading. You can’t necessarily make
    this “generic”.