Настройка миграции при обновлении до Drupal 8

Создайте свои начальные миграции

• Создайте миграции, используя drush migrate-upgrade --configure-only, как описано в разделе «Обновление с использованием Drush».
• Убедитесь, что у вас есть aconfig/syncdirectory, в который будет записан следующий шаг
• Экспортируйте миграции, используя drush config:export
• Создайте свой собственный модуль миграции
• Скопируйте только те файлы YML, которые вы хотите использовать, из каталога config/sync в каталог config/install вашего нового пользовательского модуля, отредактировав их для удаления значений uuid и редактирования идентификатора, группы, метки и других значений по мере необходимости.
• Скопируйте файл группы migrate_plus.migration_group.migrate_drupal_7.yml из config/sync в каталог config/install вашего нового пользовательского модуля, назвав его migrate_plus.migration_group.your_module.yml. Вам понадобится файл группы, поскольку он содержит настройки базы данных.

Управление миграцией

• Начните с миграции пользовательских ролей и пользователей, прежде чем переходить к узлам
• Продолжая добавлять файлы в каталог config/install, перечитайте каталог с помощью что-то вроде drush config-import --partial --source=modules/custom/your_module/config/install (для этого требуется включить модуль Config) 

Переименовать поля при обновлении до Drupal 8

Допустим, у вас на сайте Drupal 7 есть тип контента A с полями foo, bar и baz. Также допустим, что вы хотите переименовать поле baz в zot в Drupal 8. Подобные изменения довольно просто сделать, когда вы переходите с использованием drush.

• Создайте миграции, используя drush migrate-upgrade --configure-only, как указано на странице, указанной выше.
• Запустите тип узла и миграцию полей. Это сгенерирует тип контента A и поля foo, bar и baz.
• Вручную создайте поле zot в Drupal 8. Удалите базу baz, которую создали миграции, но которую вы не планируете использовать.
• Прилагаемый модуль Migrate Plus позволяет реализовывать подключаемые модули как объекты конфигурации, позволяя гибко загружать, изменять и сохранять их. Отдельные миграции, созданные с помощью drush migrate-upgrade --configure-only, теперь можно проверить, перейдя к admin/config/development/configuration/single/export и выбрав «Migration» в качестве Типа конфигурации. Выберите миграцию для узлов (A).
• Скопируйте и вставьте миграцию в admin/config/development/configuration/single/import, но измените отображение поля так, чтобы поле назначения было field_zot, но вы по-прежнему отображали источник из field_baz. Точное содержание определения миграции будет зависеть от типа поля. Чтобы понять анатомию миграций, обратитесь к примерам, приведенным в документации по Migrate API.
• После того, как вы импортировали измененную миграцию, вы можете запустить миграцию для узлов A с помощью Drush и убедиться, что данные были перенесены в поле zot правильно.
• Повторите изменение сопоставления для миграции редакций узла (A), если вы планируете также переносить редакции узла.

Другим способом достижения того же результата является ручное создание нового поля zot, как описано выше, и изменение отображения поля миграции узлов (A) путем реализации hook_migration_plugins_alter().

Написание пользовательских плагинов процессов

Если вам нужно определить собственную логику преобразования (если это, то это), вы можете подумать о написании собственного плагина процесса.

Пример в документации по Migrate API использует миграцию пользователя в качестве примера. Для определения кода языка пользователя требуется логика if-else, как описано в примере, и поэтому модуль User предоставляет собственный плагин процесса UserLangocode.

Приведенный выше пример описывает, как процесс должен быть сохранен в каталоге MODULE/src/Plugin/migrate/process и как его следует аннотировать, чтобы его можно было использовать. Используйте UserLangcode и другие плагины процессов в качестве примеров при написании своего собственного!

hook_migrate_prepare_row()

Если вам нужно определить собственную логику преобразования, вы также можете реализовать hook_migrate_prepare_row() в своем пользовательском модуле и реализовать свою логику там.

Как описывается в документации API ловушки, ловушка имеет три аргумента:

• Row $row
• MigrateSourceInterface $source
• MigrationInterface $migration

Как описано в документации API ловушки, вы можете использовать $igration->id(), чтобы ограничить свою логику только желаемой миграцией.

Чтобы прочитать исходное свойство в переменную, используйте Row::getSourceProperty(), например, если в исходной строке будет свойство с именем type, вы можете сказать: $type = $row->getSourceProperty('type');

Чтобы установить совершенно новое свойство, которое вы можете использовать в определении миграции в качестве источника, используйте Row::setSourceProperty().

Чтобы сделать запросы базы данных к исходному сайту, используйте $source->getDatabase()->query(), как показано в документации по API-интерфейсу подключения.

Чтобы пропустить строку от миграции, вы можете выдать новое исключение MigrateSkipRowException.

hook_migration_plugins_alter()

Другой способ настроить миграцию - реализовать функцию hook_migration_plugins_alter() в вашем пользовательском модуле.

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

Migrate Plus предоставляет событие PREPARE_ROW

Если вы предпочитаете писать свои пользовательские ответы на основной обработчик prepare_row объектно-ориентированным способом вместо реализации hook_migrate_prepare_row(), вы можете сделать это, если у вас включен включенный модуль Migrate Plus. Migrate Plus предоставляет событие PREPARE_ROW, на которое может подписаться ваш подписчик. Drupal 8 API документация для событий. Для примера по реализации подписчика событий в другом контексте вы можете обратиться к этому примеру из справочника модуля Simple FB Connect.