Create Local Version Control in your WordPress Plugin

We think its best to start this post of with an example. Lets say you develop and publish version 1 of a plugin, and within this first version you create a custom table in the WordPress database. Your plugin becomes successful and you release version 2 with changes to the table schema. Finally you release version 3 with more changes to the table schema and add a new table that relates to the first table.

What is the Problem and How can we solve it?

If you don’t have local version control, then you cant know what version of your plugin the client currently has installed on their site. This is a problem because you have to make different changes in your plugin depending on which version the client currently has and which one they are updating to.  Look at the follow table schemas below for each hypothetical version of your plugin.

Version 1

  • Person
    • first_name
    • last_name
    • email

Version 2

  • Person
    • first_name
    • last_name
    • email
    • street
    • zip
    • city
    • country

Version 3

  • Person
    • first_name
    • last_name
    • email
    • address
  • Address
    • street
    • zip
    • city
    • country

As you can see the table schema changes with each plugin update. If the client has version 1 installed and they are updating to version 3, then first you need to change the Person table schema to match version 2.  Next, you must add the Address table and relate it to the Person table. As you can see, without knowing what version the client currently has, it is impossible to know what changes to make. This is why its best to always store your plugin’s version locally in a WordPress database via an option.

Implementing Local version control in our WordPress Plugin

Now that we understand the problem, lets talk about the solution.  In the activation hook first check what version of your plugin is stored in the WordPress database.  Then, make the proper changes in your plugin depending on the version stored in your plugin and the one stored in the WordPress database. Once you have made the proper changes save the current version of the plugin into the WordPress database.  It should look something like this:

/* Plugin verison */

if (!defined('MY_PLUGIN_VERSION_NUM'))
    define(‘MY_PLUGIN_VERSION_NUM', '3.0.0’);

register_activation_hook( __FILE__, ‘my_plugin_register_activation’);

function my_plugin_register_activation() {

     $version_setting_name = ‘my_plugin_version’;

     $version_num = get_option($version_setting_name);

     if ($version_num !== false && isset($version_num) && $version_num == ‘1.0.0') {

          // Alter the Person table’s schema

          // Add the Address table and relate it to the Person table

          // Then update the version value

          if (is_multisite()) {
               update_site_option($version_setting_name, MY_PLUGIN_VERSION_NUM);
          } else {
               update_option($version_setting_name, MY_PLUGIN_VERSION_NUM);
          } 

     } else if ($version_num !== false && isset($version_num) && $version_num == ‘2.0.0') {
          // Add the Address table and relate it to the Person table

          // Then update the version value

          if (is_multisite()) {
               update_site_option($version_setting_name, MY_PLUGIN_VERSION_NUM);
          } else {
               update_option($version_setting_name, MY_PLUGIN_VERSION_NUM);
          }   
     } else {

          // Then update the version value

          if (is_multisite()) {
               update_site_option($version_setting_name, MY_PLUGIN_VERSION_NUM);
          } else {
               update_option($version_setting_name, MY_PLUGIN_VERSION_NUM);
          }   
     }
}

Once you have this implemented this solution, updating your plugin will be easier and much more reliable. Have a question or think there is a better way to solve this problem? Please let us know in the comments below.

Leave a Reply

Your email address will not be published. Required fields are marked *