Don't do a registry_update() before installing a module

Here's a patch for module_enable() (in 7.10) that works for my profile installation situation, which had issues with both registry_update() and drupal_get_schema() for much the same reasons. Your mileage may vary, of course.

Indeed there are many issues out there that relate to the problem of a module's methods being called before it is fully installed.

However, updating the registry before a module is enabled seems to be by design and required. Modules frequently use their own methods at install time. For this to work, their own code needs to be available. Therefore the registry needs to be updated before their install hooks are called.

The solution to this seems to be that modules need to conditionally skip certain API calls at install time (when Drupal or a module or theme is being installed). We may need a convenience method equivalent to drupal_installation_attempted() but that returns TRUE also when a module or theme is being installed.

Correct Media module issue URL.

I agree, the .module file should not be included until the module's install function has run. Any other functions could still be used if they were in other includes that could then be embedded.

I think this bug should be marked as critical as currently it stops lots of entity providing modules from being used in install profiles. We should either document that modules need to check whether tables exist in some functions OR fix this in drupal core.

This has come up again. #2313235: Fails to complete installation

Looks like the issue I just filed is eerily similar:
#2403535: module_enable() exposes module hooks before the module's schema is installed

Clean the patch file (can apply for D7.34 from now).

Here's a patch that purely moves register_update. What is the purpose of also moving drupal_get_schema?

Adding more related issues.

Pruning dupes.

#13 works for me! Sooooo glad to finally have a solution.

#13 fixes a number of entity-related modules breaking during installation with install profiles (such as Paragraphs: #2412747: Fatal error: Class 'ParagraphsItemMetadataController' not found). I haven't noticed any side effects.

I also can confirm this worked in resolving an issue with paragraphs as per #17

@nedjo's comment in #3 looks valid to me and has not been addressed. We shouldn't break modules that are currently using their own API in hook_install()...

Because of that, I'm not sure this is a bug core can or should fix, but perhaps at least it can do something (as @nedjo suggested) to make sure that contrib modules have an easy way to distinguish between a fully-installed module and one that is still in the process of being installed (if that doesn't already exist).

Looks like this should be closed out. The patch is #13 is already in core 7.43.

No it isn't: http://cgit.drupalcode.org/drupal/tree/includes/module.inc?h=7.43#n464

An implementation of hook_module_implements_alter removing the offending hook if the table doesn't exist seems to work as well.

For paragraphs (in my case) it would be something like

function MYMOD_module_implements_alter(&$implementations, $hook) {
  if ($hook == 'entity_info') {
    if (!db_table_exists('paragraphs_bundle')) {
      unset($implementations['paragraphs']);
    }
  }
}

Reset issue status.