With the new hooks in #1694792: Allow provision-deploy to move a site to a platform with different module paths, we should be able to implement a registry rebuild before database updates are run. Otherwise, we'll see errors like this when deploying sites onto platforms with modules in different locations:

The following module has moved within the file system: example. In order to fix this, clear caches or put the module back in its original location. For more information, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1128 of /var/aegir/platforms/some_platform/includes/bootstrap.inc).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

colan created an issue. See original summary.

colan’s picture

colan’s picture

Assigned: colan » Unassigned
Status: Active » Needs work
FileSize
761 bytes

I spend hours trying to get this hook implementation to fire, but nothing I tried worked. Here are all of the names I tried:

  • provision_tasks_extra_provision_deploy_pre_updatedb()
  • drush_provision_tasks_extra_provision_deploy_pre_updatedb()
  • hosting_tasks_extra_provision_deploy_pre_updatedb()
  • tasks_extra_provision_deploy_pre_updatedb()

Anyone know what's wrong?

memtkmcc’s picture

I think that drush_provision_tasks_extra_provision_deploy_pre_updatedb() should work, since it follows the naming convention used in all other extra tasks.

Anyway, it will not work when defined in the "Aegir Hosting Tasks Extra" module, because this hook is fired only in the deploy.provision.inc file, in drush_provision_drupal_post_provision_deploy(), which is not fired in "Aegir Hosting Tasks Extra" automatically, because here you run just updatedb. Also, you don't really want to run the full drush_provision_drupal_post_provision_deploy() here, hence you will never be able to trigger drush_command_invoke_all('provision_deploy_pre_updatedb');

Maybe this hook should be moved outside of drush_provision_drupal_post_provision_deploy() to be really re-usable.

In fact, I'm not sure if this extra level of abstraction is really needed, since it seems to just add more confusion, and you still need to duplicate some code anyway, to get these hooks fired.

Also, you can't really even access drush_provision_drupal_post_provision_deploy() from the contrib module, unless you will add this snippet within drush_provision_tasks_extra_provision_update():

  $list = drush_commandfile_list();
  $provision_dir = dirname($list['provision']);
  include_once($provision_dir . '/platform/deploy.provision.inc');

I don't think this makes much sense, though..

It is just too much (confusing) work, while all you really need is something like:

/**
 * Implements the provision-update command.
 */
function drush_provision_tasks_extra_provision_update() {
  drush_errors_on();
  // Run registry-rebuild without cache-clear, if available.
  if (function_exists('drush_registry_rebuild')) {
    if (drush_drupal_major_version() < 8) {
      provision_backend_invoke(d()->name, 'registry-rebuild --no-cache-clear');
      drush_log(dt('Registry rebuilt with --no-cache-clear in drush_provision_tasks_extra_provision_update'));
    }
  }
  $options = d()->options;
  if (isset($options['entity_updates']) && $options['entity_updates'] && drush_drupal_major_version(d()->root) >= 8) {
    provision_backend_invoke(d()->name, 'updatedb',  array('--entity-updates'));
    drush_log(dt('Drush updatedb task completed with --entity-updates'));
  }
  else {
    provision_backend_invoke(d()->name, 'updatedb');
    drush_log(dt('Drush updatedb task completed w/o --entity-updates'));
  }
  // Run registry-rebuild with cache-clear, if available.
  if (function_exists('drush_registry_rebuild')) {
    if (drush_drupal_major_version() < 8) {
      provision_backend_invoke(d()->name, 'registry-rebuild');
      drush_log(dt('Registry rebuilt without --no-cache-clear in drush_provision_tasks_extra_provision_update'));
    }
  }
}

It is my pure speculation, so I could be totally wrong, but maybe it helps?

colan’s picture

Regarding the code above, entity updates should no longer be run automatically (or at all). See #3029042: Add '--entity-updates' when we run database updates (for D8) for details.