Сохранение связи терминов при переносе узлов

Ознакомьтесь со всеми примерами миграции в руководстве по миграции d2d.

Имеется документация по миграции терминов таксономии и миграции узлов.

Поместите их вместе с документацией для миграции.

Кроме того, мигрируют, перенос дополнительных модулей и перенос модулей d2d во всех них есть примеры модулей, которые содержат очень полезный пример кода. В частности, ознакомьтесь с примером модуля в migrate_d2d, у него есть пример этого.

Там много документации, но это потому, что миграция - сложная задача. Чем больше вы читаете и чем лучше понимаете, тем легче это дается и тем лучше результат.

После того, как вы сделали пару миграций, это становится намного проще.

Для узлов и их таксономий сначала переносятся термины, а затем узлы. Модуль переноса будет отслеживать сопоставление старого идентификатора термина с новым идентификатором термина, затем, когда дело дойдет до узлов, он будет использовать это сопоставление для терминов, прикрепленных к узлам.

Вот как вы отображаете поле таксономии:

Когда вы регистрируете свои крючки:

// Each migration being registered takes an array of arguments, some required
// and some optional. Start with the common arguments required by all - the
// source_connection (connection key, set up in settings.php, pointing to
// the Drupal 6 database) and source_version (major version of Drupal).
$common_arguments = array(
  'source_connection' => 'legacy', // This is the name of a connection in your settings.php file.
  'source_version' => 6, // This is the source drupal version.
);

// Other migration registration here, like users & files.

// For vocabulary migrations, source_vocabulary and destination_vocabulary are
// required arguments. Note that in Drupal 6 vocabularies did not have machine
// names, so we use the vocabulary ID to uniquely identify them.
$vocabulary_arguments = array(
  array(
    'description' => t('Migration of Tags terms from Drupal 6'), // Description for this migration
    'machine_name' => 'Tags', // Migration machine name
    'source_vocabulary' => '5',  // Source vocabulary ID
    'destination_vocabulary' => 'tags', // Destination vocab machine name.
  ),
  array(
    'description' => t('Migration of Category terms from Drupal 6'), // Description for this migration
    'machine_name' => 'Category', // Migration machine name
    'source_vocabulary' => '6',  // Source vocabulary ID
    'destination_vocabulary' => 'category', // Destination vocab machine name.
  ),
  // More migrations for other vocabs.
);

// We're using the migrate_d2d class directly for all of the above.
// You can put other common params here.
$common_vocabulary_arguments = $common_arguments + array(
  'class_name' => 'DrupalTerm6Migration',
);
foreach ($vocabulary_arguments as $arguments) {
  $arguments += $common_vocabulary_arguments;
  // Register the migrations.
  Migration::registerMigration($arguments['class_name'], $arguments['machine_name'], $arguments);
}


// Node migrations.
$node_arguments = array(
  array(
    'class_name' => 'PageMigrationClassName', //  The class name for this migration as we are extending a built in one.
    'description' => t('Migration of page nodes from Drupal 6'), // Description for this migration.
    'machine_name' => 'Page', // Machine name of this migration.
    'source_type' => 'page', // The node type in the old site.
    'destination_type' => 'page', // The node type in the new site.
    // Dependencies. This means this won't run until after the Tags & Category migrations have run.
    'dependencies' => array('Tags', 'Category'),
  ),
  // Other nnode migrations here.
);
foreach ($node_arguments as $arguments) {
  $arguments += $common_arguments;
  // Register the migrations.
  Migration::registerMigration($arguments['class_name'], $arguments['machine_name'], $arguments);
}

Теперь в коде миграции узла страницы вы должны сделать:

class PageMigrationClassName extends DrupalNode6Migration{
  public function __construct(array $arguments) {
    parent::__construct($arguments);

    // Note that we map migrated terms by the vocabulary ID.
    // This is for the Tags vocab.
    // The first param is for the D7 field name.
    // The second param is for the old site's vocab ID.
    // This is how it is stored on the row, eg. $row->5
    $this->addFieldMapping('field_tags', '5')
         ->sourceMigration('Tags') // This is the machine name of the tags migration.
         // This tells the migration to match on the term ID instead of the default, which is the term name.
         ->arguments(array('source_type' => 'tid'));

    // And for the category vocab.
    $this->addFieldMapping('field_category', '6')
         ->sourceMigration('Category')
         ->arguments(array('source_type' => 'tid'));
  }
}

Если вы хотите сопоставить данные с данными, которые уже находятся в новой системе и не были перенесены с помощью модуля переноса, вероятно, есть несколько способов сделать это. Один из способов - использовать API миграции методы.

Вы можете реализовать prepareRow() в своем классе миграции узлов и сделать это:

public function prepareRow($row) {
  // Always include this fragment at the beginning of every prepareRow()
  // implementation, so parent classes can ignore rows.
  if (parent::prepareRow($row) === FALSE) {
    return FALSE;
  }

  // The node's terms are in an array under their vocab ID.
  if (!empty($row->{5})) {
    foreach ($row->{5} as &$tid) {
      // Code here to map term IDs from old to new.
      // Set $tid to the corresponding new site tid.
      // You could call a separate mapping function to do this if you have
      // a lot of terms or complex mapping requirements or something.
    }
  }
  return TRUE;
}

В качестве альтернативы вы можете поместить новые tid в другое место в строке $, например:

$row->mapped_tids_tags = array(3, 7, 4, 8, 6);

Тогда для вашего картографа полей у вас есть:

$this->addFieldMapping('field_tags', 'mapped_tids_tags')

Вместо:

$this->addFieldMapping('field_tags', '5')