If some errors occurs in the process of enabling modules (WSOD due to OOM and others), it happens that the modules are shown as enabled. But in such cases the features of those modules are broken since the enabling/installing of the modules were not completely run.

How do I detect such modules state without re-enabling every single module?

Update: Obviously logs can be disabled/cleared/lost, don't mention them please.

  • 2
    This is a totally legit question and should be reopened. It is totally clear what the user asks: what modules are in such a state where module_enable started but didn't finish. The answer is: this can't be done in general if watchdog is pruned because drupal_set_installed_schema_version runs before hook_install and hook_enable. If you want, write a module which logs to a safe place in a hook_modules_enabled implementation (last to run) and compare that with the state of the module in {system}. If the schema_version is > -1 but it's not in your special log you have a broken module – user49 Nov 29 '15 at 9:31
  • 3
    Also, I thought we have a voting system for closing questions and ♦ users shouldn't just close a question on whim? I have heard complaints in the past that Drupal SE is not in line with "the Drupal community is welcoming" philosophy and I'm not particularly happy to see it in action. Escalating. – user49 Nov 29 '15 at 9:40

The problem is that it depends on each module. When enabled, a module sets up its environment (create tables, variables, declare URL, etc) but this environment is not declared explicitly so you can't automatically check that the module has been installed correctly.

You may check the install file for the modules's scheme (tables defined by the module) and the hook_enable to see what tasks needs the module when is enabled.

I think best way is to uninstall modules and try to install them again, so all modules's environent are cleared when unisntalling and set up again when enabled again.

Using drush this tasks is very easy and handy.

Ah, and try to clear caches to see if modules works, but you won't be sure modules installed correctly...

  • The first paragraph of this is the only possible answer to the question. There's no one single 'state' that defines when a module is 'successfully' enabled or not. Drupal checks the status column in the system table to see if it's been enabled, but it cannot detect when a module has failed to install because of a memory timeout/fatal error, because such a thing can't be strictly defined. Even if it could be strictly defined, Drupal doesn't. – Clive Mar 14 '14 at 12:12
  • Well, maybe. Now I'm wondering why does Drupal set it to enabled before actually enabling. – int_ua Mar 14 '14 at 12:15
  • Are you positive that's what it does? Don't forget, there are 3 states a module can be in: disabled, installed and enabled, and various hooks available for modules to make changes at any of those states – Clive Mar 14 '14 at 12:17
  • Totally positive. Regardless of the name. Enabled modules must be installed. Isn't that reasonable? – int_ua Mar 14 '14 at 13:40
  • 2
    May be Drupal could add a new state, installing, that changes to installed when all task are done. But this introduce more complexity in system (module has more state to check, more posibilities) and it doesn't really resolve a big issue. Half installed modules only happens when a server error occurs (PHP memory, time exceeded and so on, errors that should not happen in aproduction environment) or bad behaviored or development modules (again, shoud not happen in production). If you reaslly think is a needed functionality you can fill a bug report in the core issue queue. – sanzante Mar 14 '14 at 13:50

You should check the dblog at /admin/reports/dblog after such situation. You can also see error_log file in the Drupal root installation folder.

  • dblog can be disabled or cleared. I've never seen error_log in Drupal root. Apache logs also can be empty. – int_ua Mar 14 '14 at 11:44
  • Keep it enabled when do such activity. – AgA Mar 14 '14 at 11:46
  • There are situations when you get a site in already broken state, you know. – int_ua Mar 14 '14 at 11:50
  • Please change your question accordingly. Don't change it here. Re-edit it. – AgA Mar 14 '14 at 11:52

Using drush, you can check if module is enabled by:

drush pm-list | grep foo

If the installation process stops, try:

  1. Refreshing the page again (with POST-ing the data again)
  2. Enable module one of each time.
  3. Clear caches (drush -y cc all).
  4. Check the .install file from the module directory to see what tables it should create and other data during the installation. If the installation is broken, re-install it (drush -y dre when using Devel).

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