update

I have written lots of detail about using update hooks to manage updates in Drupal and they have all been about the hook_update_N() hook. The hook_update_N() hook is just one of the options available in running updates as the update pipeline also includes hook_post_update_NAME(). The hook_deploy_NAME() hook, bundled with Drush 10, can also be used as an update hook in the same way.

Each of these update hooks has a number of different best practices when considering their use. All of these hooks are run once and once only and the key idea is that they take Drupal (or a module) from one version to another by adding database changes or configuration updates as the module gets updated.

For example, if you have a module that has a database table then it will be stored as schema information within your module. Once you release the module you must ensure that everyone who already has the module installed can still use it after the schema has changed. This means that as well as updating the schema information you also need to provide steps in the update hooks to update existing installs. Without this step the module would likely crash as it attempts to inject data into tables or fields that don't exist.

I perform a lot of Drupal updates, and they mostly go very well. The code updates without incident and the database updates apply whatever updates they need without a hitch. Every now and then, however, I will come across a project that hasn't received updates in a while, which means there are a lot of database updates to run through.

Having Drupal run 100+ database updates across modules and core can be a bit problematic. Some modules will require core updates to happen first, and when this happens out of order the database update update fails spectacularly.

I had to update a Drupal 7 site recently and needed to change the field keys of a list field to be different values. This wasn't possible from within Drupal as it does a pre-check to make sure that the key doesn't already exist. If it finds any values present in the database with that key then it will reject the change. This is absolutely correct but causes a little bit of an issue when you need to update these values.

The solution to this is to alter both the field definition and the field data via directly altering them in the database. The following function provides a neat little way of doing this to a field by just passing in the field name and what the key values need to change to.