There was a big problem: After some investigation, I discovered that the problem came from the options used by the plugin: These values were important, so I needed a way to create the default values. For example, when you manually update the WordPress files to a new version, the platform will ask you to hit a button to update the database too.
Assume that you use options in your plugin. Creating new options when a user activates your plugin for the first time is easy, you just have to use the activation hook.
If you want a new option, or if you update the value of an existing option in a new version, you need to update the database of users who already use your plugin, so we need a function called right after the update.
The activation hook can seem a bit confusing. After all, when you automatically update a plugin, it is deactivated and reactivated, so we could expect this hook to be called. To be more precise, it was, but WordPress stopped this behavior in version 3. The development team explained this choice, and you can read the entire explanation on the Make WordPress Core blog.
The number in the database will store the version currently installed by the user, while the number in the constant is the current version. In this case, we call a function that updates all the necessary options. This function also updates the version number stored in the database: First, add a constant definition in the main file of your plugin, with your current version number as a value. In order to prevent any problems, we test if it does not exit yet.
The only constraint here is to have a unique identifier for each version or, at least, for each version which requires changes in the database new options, new default values, etc.
The Checking Function We need now to write a function that will check if the database needs to be updated. This function will compare the previously defined constant with the value currently stored in the database. We retrieve the version number stored in the database, as any other option, and we compare it to the constant.
So why do we call the activation function? To be clear, we could create a new function, dedicated to the update process. Updating the Version Number in the Database You can do whatever you want in the activation function called above. However, there is one thing needed, updating the version number stored in the database.
If it exists, it will update its value to the indicated one. Updating any option can be done the same way we updated the version number: Otherwise, we create the option. A Special Case — Arrays You should know that WordPress allows arrays to store values for our options, and creating them is not any more difficult that creating other options.
However, this can cause issues when we think about the update process. To understand why, assume that you have an array as an option, with some keys. Your users will surely personalize these values. It seems straightforward, but what if you want to create a new key in your array? But if we erase the condition, the array will retrieve its default values with each new update. First, we define an array containing the default values of our options with the new keys if they exist. If the user has changed one of the old options, their values will be kept.
The fact is, considering the problems we listed above, if we see this type of feature introduced one day, it should be implemented in a similar way to this tutorial. You can get the code for my example plugin here. Treat this code as a skeleton for you to implement your own WordPress plugin update process. If you have any feedback, please let me know in the comments below. He loves learning new things and sharing his knowledge with others.