1

The problem is, it seems when I enable a disabled module, the module's schema version in the system table is automatically updated to the latest version supplied by hook_update_N.

So my current module with the schema version -1 is modified to 7106 when I enable the module, and no hook_update_N functions are run.

So when I come to the next step of running database updates, no hook_update_N functions are run because the module thinks it's already the correct version.

The only method I can see is to manually set the module version in hook_enable, however I'll then need to update the module code to remove the hook_enable to make sure it doesn't run if the module is ever re-enabled in the future, so obviously this approach is a bit dirty.

I'm hoping there's a better solution?

5

Disabling a module should not set the schema_version to -1. -1 means SCHEMA_UNINSTALLED. As the constant says, it means this module has never been installed.

A module that has not been installed before is not supposed to run updates. hook_schema() is supposed to contain the current state of a module's schema. So this behavior is correct, and you should not mess around with the schema version manually.

If disabling (not uninstalling) a module really does set the schema_version to -1, then that's where things go wrong. But Drupal core isn't doing this, see module_disable().

Also, note that Drupal executes updates for all installed modules, no matter if they're enabled or not.

  • "hook_update_n executes for all modules whether they are enabled or disabled" - I have observed this as well. Could someone validate this statement with a reference? – texas-bronius Sep 17 '13 at 15:24
  • It's not a statement, it's a fact :) But if you don't want to believe my word, read the code: api.drupal.org/api/drupal/includes%21update.inc/function/…. That loads all modules and skips only those that are uninstalled. – Berdir Sep 17 '13 at 18:49
0

Uninstall the module (drush pm-uninstall) and then enable it again.

  • The module is part of a feature, so we need to have hook_update_N run after the feature revert, rather than hook_install which I imagine would happen before feature revert? – DanH Jan 18 '12 at 3:24
0

Ok looks like the only way I can think of would be to manually set the schema_version to 0 for the disabled module, as this seems to prevent it from inheriting a more advanced version number.

Still feels a little dirty, but at least I can handle this with SQL used in a deployment script rather than rely on hooks that could run more than once.

  • There are many Drupal modules, and none of them does what you are describing. – kiamlaluno Aug 29 '12 at 16:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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