`drush enable` not running hook_install in modules enabled for the first time

I don't think this problem is specific to Views, I seem to get it on several modules and I'm using the most current dev version as well...? The issue appears to be that the install hook isn't being called any more? ...Or perhaps the install_schema??? How to tell?

Am using Leopard with MAMP and a self compiled apache environment on a Leopard dev box.

Pobster

I am getting this error as well, only views is not installing correctly.

Looking into the views.install file, it looks like the cache_views schema is being loaded differently from the other table schemas:

 $schema['cache_views'] = drupal_get_schema_unprocessed('system', 'cache'); 

Could this be the source of the issue?

I got errors with date module:

$ drush enable date
The following modules will be enabled: date, date_api, date_timezone
Do you really want to continue? (y/n): y
Date was enabled successfully.                                       [ok]
Date API was enabled successfully.                                   [ok]
Date Timezone was enabled successfully.                              [ok]
user warning: Table 'drupal-gtf.date_format_types'         [error]
doesn't exist
query: SELECT dft.type, dft.title, dft.locked FROM date_format_types
dft ORDER BY dft.title in
/home/gtf/public_html/sites/all/modules/date/date_api.module on line
1963.
user warning: Table 'drupal-gtf.date_format_types'         [error]
doesn't exist
query: SELECT dft.type, dft.title, dft.locked FROM date_format_types
dft ORDER BY dft.title in
/home/gtf/public_html/sites/all/modules/date/date_api.module on line
1963.
An error occurred at function : drush_pm_enable                          [error]

Is this related?

Yes it is, as I mentioned in my post - this isn't specific for Views, it happens with most modules I enable through Drush... Their install hooks are simply ignored hence the tables not being found afterwards.

Pobster

Content (cck) is another module where this happens. The tables that had issues appeared to both be _cache tables, not sure if that's relevant.

Not sure if it's relavent but I realized the two modules that had issues are doubles; ie they exist under 2 files, in this case sites/all/modules and modules/acquia; didn't realize the were in the later.

Same problem here, on Views.
I get the message telling Views was successfully installed, then a lot of SQL errors telling that many tables don't exist (at least cache_views and views_view).
I have only one instance of my code (as opposed to hefox).
When I check in my database, the tables are here so maybe some hooks are called in a wrong order?

I experienced the same problem with HEAD.

Just found a possible reason.
Check drush/commands/pm/pm.drush.inc file.

It first calls module_enable($modules), then, later, drupal_execute('system_modules', $form_state); (lines 242 to 270).

Actually, module_enable does not install a module, thus, does not run its hook_install.

By the way, running drupal_execute('system_modules', $form_state); clears a lot of cache, invokes a lot of hooks, and, among these hooks, are those of Views (or whatever module you just enabled), which won't find its tables (cache_views, views_view, ...).

Just commenting the line 270 drupal_execute('system_modules', $form_state); removes the errors, but does not install the module at all: the tables are not created.

I suggest to use the function drupal_install_modules($modules) to install those modules that were not installed before...

It worked for me by changing `module_enable($modules)` by

require_once DRUPAL_ROOT . '/includes/install.inc';
drupal_install_modules($modules);

as suggested by David Stosik :).

David, do you wanna roll a patch?

A side note: is enough to do `require_once '/includes/install.inc';`(whithout DRUPAL_ROOT) as drush has set the working directory already to the drupal root. I think whithout DRUPAL_ROOT is the preferred way.

Here it is.

I did a few testing, and it seemed OK:
I tried to enable a module, then disable it, the enable it again, then disable it, then uninstall it, and I also tried to install a module which has uninstalled dependency, and these tests worked.

Regards,
David

reviewed :)

Me too/subscribe.

Marked #572594: Error installing xmlsitemap on empty site as a duplicate of this issue. Also subscribing. Kind of a bad bug...

@Owen - could you take a look? AT least lets get this right for dt5/d6 and then tackle d7 since it needs significant work for pm commands.

@David

thanks for the patch. had the same issue while installing xmlsitemaps and its now fixed with ur patch.

Works well with D6, but in D5 drupal_install_modules() only installs new modules, ignoring any that were installed previously and disabled.

Committed. Thanks.

Would be terrific if someone could refactor the D7 code for enable/disable/uninstall to make sure we take advantage of the new graph.inc which assures that module operations happen in dependency order.