Last updated April 8, 2015. Created on November 15, 2013.
Edited by mikeryan, Cottser. Log in to edit this page.

Quite frequently, hooks defined by other modules firing during migration (as a result of node_save(), user_save(), etc.) cause various problems - most often it's simply a performance impact (use the timer instrument to identify these), but sometimes it's actually dangerous (such as sending email notifications). With Migrate 2.6 and later, hooks belonging to other modules can be disabled in the migration configuration.

In your hook_migrate_api() implementation, add an array keyed by 'disable_hooks' to the arguments to your group or migration definition. Each entry in the array will be keyed by a hook name, and the value will be an array of modules for which to disable that hook. Here's a real-world example for a migration into Drupal Commons, where there are many, many hooks firing and substantial pruning is needed to achieve reasonable migration performance:

<?php
  $disable_hooks
= array(
   
'comment_insert' => array(
     
'commons_activity_streams',
     
'commons_follow_node',
     
'commons_notify',
     
'commons_radioactivity',
     
'search',
     
'expire',
    ),
   
'comment_publish' => array(
     
'search',
     
'xmlsitemap_node',
     
'expire',
    ),
   
'comment_update' => array(
     
'commons_activity_streams',
     
'commons_follow_node',
     
'commons_notify',
     
'commons_radioactivity',
     
'search',
    ),
   
'entity_insert' => array(
     
'metatag',
     
'og',
     
'registration',
    ),
   
'entity_presave' => array(
     
'pathauto',
    ),
   
'entity_update' => array(
     
'metatag',
     
'og',
     
'registration',
    ),
   
'flag' => array(
     
'commons_radioactivity',
    ),
   
'node_insert' => array(
     
'commons_activity_streams',
     
'commons_follow_group',
     
'commons_follow_node',
     
'commons_groups',
     
'commons_notify',
     
'commons_radioactivity_groups',
     
'kwresearch',
     
'pathauto',
     
'xmlsitemap_node',
     
'expire',
    ),
   
'node_update' => array(
     
'commons_activity_streams',
     
'commons_follow_group',
     
'commons_follow_node',
     
'commons_groups',
     
'commons_radioactivity_groups',
     
'kwresearch',
     
'pathauto',
     
'xmlsitemap_node',
     
'expire',
    ),
   
'node_prepare' => array(
     
'og_menu',
    ),
   
'taxonomy_term_insert' => array(
     
'metatag',
     
'pathauto',
     
'shs',
     
'taxonomy_menu',
    ),
   
'taxonomy_term_update' => array(
     
'pathauto',
     
'shs',
     
'taxonomy_menu',
    ),
   
'user_insert' => array(
     
'pathauto',
    ),
   
'user_update' => array(
     
'pathauto',
    ),
   
'votingapi_insert' => array(
     
'expire',
    )
  );

 
$api = array(
   
'api' => 2,
   
'groups' => array(
     
'example' => array(
       
'title' => 'Example Project',
       
'disable_hooks' => $disable_hooks,
      ),
    ),
   
'migrations' => array(
...
?>

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

hussainweb’s picture

Is there a way to disable all hooks in a particular module?

scottatdrake’s picture

At risk of stating the obvious-- you could just disable that particular module before starting the migration, yeah?

hussainweb’s picture

This is not always possible. The sites we build are completely featurized and have all dependencies setup. Sometimes, disabling the module (such as rules) will disable other modules that may be required for migration. Further, it is not always easy to ensure that the module is disabled when testing after each change.

Anyway, I sorted out this problem by directly implementing hook_module_implements_alter() in my migration module. It is a bit risky but works if you really need it.

jan_v’s picture

This saved my day. Apache Solr module kept updating every single node handled in the migration. This slowed down the migration significantly.