Drupal: what to do when tables won’t install during module development
Posted on: November 10, 2009
- In: content management | drupal | PHP
- 8 Comments
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.
8 Responses to "Drupal: what to do when tables won’t install during module development"
February 15, 2010 at 11:02 am
Thank you, just what I needed to know. Saved me from pulling my hair out!
January 18, 2011 at 12:42 am
Hi Paul and Lacey,
Thanks for the tips but i gotta question for you if i re enable the module does the database loses the content that are previously stored.
January 18, 2011 at 9:20 am
As this article outlines, disabling and then re-enabling the module has no effect on existing module-related tables, but if you’re running the install functions again (ie: you’ve disabled your module, removed the related entry from the system table and removed any module-related tables) then your existing db data will be lost.
Trying to run the module install again without removing the old tables will make MySQL complain that the table aready exists UNLESS your install functions include SQL command/s to drop the old tables before the install runs.
Hope that helps 
Paul
December 4, 2009 at 8:17 am
It would be helpful if you describe how to remove a module table from a database…
February 15, 2010 at 11:21 am
Hi ahimsa,
A handy bit of sql will do the trick:
“drop table TABLENAME;”
Paul
April 18, 2010 at 12:54 pm
This can also be done though your module (rather than direct interaction with the database) by adding hook_enable and hook_disable implementations as follows:
Just make sure to remove these hooks after module development unless you want user submitted to be lost on disable!
April 18, 2010 at 1:50 pm
The Code (was removed last time)
/**
* Implementation of hook_install().
* Called when you “check” your module
*/
function modulename_enable() {
drupal_install_schema(‘modulename’);
}
/**
* Implementation of hook_disable().
* Called when you “uncheck” your module
*/
function modulename_disable() {
drupal_install_schema(‘modulename’);
}
April 21, 2010 at 4:00 pm
Thanks for the tip Lacey – good to know there’s a more “Drupal” way to achieve this