I am porting a module to Drupal 7. The module has hook_update_N() functions called from hook_install(). There are some insert queries made inside one of the hook_update_N() functions. But my hook_update_N function is not running. Is there any way to explicitly invoke hook_update_N functions?

I know my question is almost same as this How to get hook_install() to run all hook_update_N()?. But I don't understand how hook_update_N() is called. I have run updates in my Drupal site which I think also run updates of custom modules but it seems hook_update_N() is not getting triggered. Because, I have added error_log() function inside hook_update_N() but the log file is empty.

up vote 6 down vote accepted

Drupal stores which update hooks has been run as it only runs the update hooks once. If a specific update hook is not run, the most probable reasons is

  • It has already been run
  • An update hook that needs to be run before fails.

You can see in the system table all the modules enabled and the schema_version shows which update has been run last.

  • thank you!! your hint "see in the system table" helped me a lot! – subhojit777 Apr 12 '12 at 5:49
  • Do you know of any other reasons? Is -1 a special case? Do you know the significance of it? – htoip Apr 6 '17 at 20:01

Another reason why an update hook would not run is a mismatch between the update hook name and the major release number of the module (see .info file).

For example: the update hook mymodule_update_7001 does not run if the module version is 7.x.1.0. In such case you must rename the hook to mymodule_update_7101.

See the hook_update API documentation

  • 1
    This just saved me an unknown number of further debugging hours! Thanks! – Pryo Jul 2 '15 at 10:33
  • 1
    For me it was also this 1.x missmatch with 7100, thanx – Marko Blazekovic Jul 22 '16 at 11:10

I had an issue where I installed a new module, but the install failed. The schema_version remained at -1, which prevented further updates for that module. Setting the version to 0 fixed it.

For the curious, I moved the schema of an existing table to a new module. The failure happened when it couldn't create the existing table, which I expected. The module was enabled as expected, but I didn't realize that the schema_version didn't update.

  • 1
    I had a similar issue where an enabled and functioning custom module's schema_version was set to -1. AFAIK it was only installed once and didn't fail to install because the module is in use today. I don't know why it's schema_version was set to -1. Anyway, I manually updated the schema_version to 0 so it would recognize and run my custom_update_7000 when I needed to add a column to an existing table that was installed with the module a long time ago. – Wesley Musgrove Apr 18 at 14:28

One reason hook_update_N() function won't do anything is that an update with the same or higher number (than the number you used on your hook_update_N() function) has already run.

You can see the last update number that ran for your module by querying the 'system' table on Drupal 7. 'schema_version' is a column on the 'system' table that stores the version number of the last update applied to your module. For your new hook_update_N() function to work, the number (N) you use on it has to be higher than the number currently stored in the 'schema_version' column for that module.

I used the following query in MySql command line (after first issuing a 'use' command to specify my Drupal 7 database name).

mysql> select name, type, status, schema_version from system where type = 'module' and name = 'my_module_name';

The 'schema_version' column will have a number. The number you use on your new update function must be higher than that.

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.