Jun 05, 2022
1 mins read
I have written lots of detail about using update hooks to manage updates in Drupal and they have all been about the hookupdateN() hook. The hookupdateN() hook is just one of the options available in running updates as the update pipeline also includes hookpostupdateNAME(). The hookdeploy_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.