paul bennett

Posts Tagged ‘modules

Drupal’s module installation system makes it very easy to extend and customise Drupal sites and to disable and re-enable modules quickly and non-destructively. However, the default way Drupal’s treats modules can get in the way during development.

When building your own modules, it’s common for database table structure to change as project needs become clearer, or even for modules to be built in a “front to back” fashion – where the admin screens and the UI interaction skeleton is built before the underlying processing and data storage code is developed (or finalised).

If this is the case, you may find yourself building an install file late in module development and then wondering why Drupal seems to dutifully ignore it.

Despite being counter-intuitive, this behaviour has some clear benefits. Previously installed modules may have attached database tables, and these tables may still hold valid application data. Drupal’s behaviour ensures that these tables aren’t destroyed when the module is disabled. The module can then be re-enabled later without any data destruction.

To get a module to run an install file, or to re-install successfully, you need to do more than just disable and re-enable the module on the module list screen (/admin/build/modules). This is beacuseĀ  Drupal keeps a record of previously installed modules and won’t reinstall them if they are merely disabled and re-enabled.

The trick to getting your new / updated install file to run is to remove the modules entry from the system database tables. If your module has already created one or more tables, and you want the table structure to be altered or rebuilt, you may also need to remove these tables before re-enabling the module.

Once you’ve disabled your module, removed the related entry from the system table and removed any module-related tables, you can re-enable the module and your install file will be run correctly.

Advertisements

Archives