Migrationseinstellungen beim Upgrade auf Drupal 8

Erstellen Sie Ihre Startmigrationen

• Erstellen Sie Migrationen mit drush migrate-upgrade --configure-only, wie im Abschnitt „Upgrade mit Drush“ beschrieben.
• Stellen Sie sicher, dass Sie ein config/sync-Verzeichnis haben, in das der nächste Schritt geschrieben wird.
• Exportieren Sie Migrationen mit drush config:export.
• Erstellen Sie Ihr eigenes Migrationsmodul.
• Kopieren Sie nur die YML-Dateien, die Sie verwenden möchten, aus dem Verzeichnis config/sync in das Verzeichnis config/install Ihres neuen benutzerdefinierten Moduls und bearbeiten Sie sie, um UUID-Werte zu entfernen und ID, Gruppe, Label sowie andere Werte nach Bedarf anzupassen.
• Kopieren Sie die Datei migrate_plus.migration_group.migrate_drupal_7.yml aus config/sync in das Verzeichnis config/install Ihres neuen benutzerdefinierten Moduls und benennen Sie sie in migrate_plus.migration_group.your_module.yml um. Diese Gruppendatei ist notwendig, da sie die Datenbankeinstellungen enthält.

Migrationsmanagement

• Beginnen Sie mit der Migration von Benutzerrollen und Benutzern, bevor Sie zu Nodes übergehen.
• Fügen Sie weiterhin Dateien in das Verzeichnis config/install hinzu und importieren Sie das Verzeichnis mit einem Befehl wie drush config-import --partial --source=modules/custom/your_module/config/install (dies erfordert das Aktivieren des Config-Moduls).

Felder beim Upgrade zu Drupal 8 umbenennen

Angenommen, Sie haben in Drupal 7 einen Inhaltstyp A mit den Feldern foo, bar und baz. Sie möchten das Feld baz in Drupal 8 in zot umbenennen. Solche Änderungen sind relativ einfach umzusetzen, wenn Sie mit Drush upgraden.

• Erstellen Sie Migrationen mit drush migrate-upgrade --configure-only, wie oben beschrieben.
• Führen Sie die Node- und Feldmigration durch. Dadurch werden der Inhaltstyp A und die Felder foo, bar und baz erzeugt.
• Erstellen Sie das Feld zot in Drupal 8 manuell. Entfernen Sie das baz-Feld, das durch die Migration erstellt wurde, aber das Sie nicht verwenden möchten.
• Das beigefügte Modul Migrate Plus ermöglicht die Implementierung von Plugins als Konfigurationsobjekte und erlaubt flexibles Laden, Ändern und Speichern. Die einzelnen Migrationen, die mit drush migrate-upgrade --configure-only erzeugt wurden, können unter admin/config/development/configuration/single/export überprüft werden, indem Sie „Migration“ als Konfigurationstyp auswählen. Wählen Sie die Node-Migration (A) aus.
• Kopieren und fügen Sie die Migration unter admin/config/development/configuration/single/import ein, ändern Sie dabei das Feld-Mapping so, dass das Ziel-Feld field_zot ist, aber die Quelle weiterhin field_baz bleibt. Der genaue Inhalt der Migrationsdefinition hängt vom Feldtyp ab. Um die Struktur von Migrationen zu verstehen, sehen Sie sich die Beispiele in der Migrate API-Dokumentation an.
• Nachdem Sie die geänderte Migration importiert haben, können Sie die Node-Migration A mit Drush ausführen und prüfen, ob die Daten korrekt in das Feld zot übertragen wurden.
• Wiederholen Sie die Änderung der Zuordnung für die Revisionen-Migration des Nodes (A), falls Sie auch Revisionen migrieren möchten.

Eine andere Möglichkeit, dasselbe Ergebnis zu erreichen, besteht darin, das neue Feld zot manuell zu erstellen und die Node-Migrationszuordnung (A) über die Implementierung von hook_migration_plugins_alter() zu ändern.

Eigene Prozess-Plugins schreiben

Wenn Sie eigene Transformationslogik benötigen („wenn dies, dann das“), sollten Sie erwägen, ein eigenes Prozess-Plugin zu schreiben.

Ein Beispiel in der Migrate API-Dokumentation verwendet die Benutzermigration. Um die Benutzersprache zu definieren, wird eine If-Else-Logik benötigt, daher stellt das User-Modul das eigene Prozess-Plugin UserLangcode bereit.

Das obige Beispiel beschreibt, wie der Prozess im Verzeichnis MODULE/src/Plugin/migrate/process gespeichert und annotiert werden sollte, damit er verwendet werden kann. Nutzen Sie UserLangcode und andere Prozess-Plugins als Beispiele beim Schreiben eigener Plugins!

hook_migrate_prepare_row()

Wenn Sie eigene Transformationslogik definieren möchten, können Sie auch hook_migrate_prepare_row() in Ihrem benutzerdefinierten Modul implementieren und dort Ihre Logik umsetzen.

Wie in der API-Dokumentation beschrieben, hat der Hook drei Argumente:

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

Wie beschrieben, können Sie $migration->id() verwenden, um Ihre Logik nur auf die gewünschte Migration zu beschränken.

Um eine Quell-Eigenschaft in eine Variable zu lesen, verwenden Sie Row::getSourceProperty(), z. B. $type = $row->getSourceProperty('type'); wenn die Quelle ein Feld namens type hat.

Um eine neue Eigenschaft zu setzen, die in der Migrationsdefinition als Quelle verwendet wird, verwenden Sie Row::setSourceProperty().

Um Datenbankabfragen an die Quellseite zu stellen, verwenden Sie $source->getDatabase()->query(), wie in der Datenbank-API-Dokumentation gezeigt.

Um eine Zeile von der Migration auszuschließen, können Sie eine neue Ausnahme MigrateSkipRowException werfen.

hook_migration_plugins_alter()

Eine weitere Möglichkeit, Migrationen anzupassen, besteht darin, in Ihrem benutzerdefinierten Modul die Funktion hook_migration_plugins_alter() zu implementieren.

Wie in der API-Dokumentation beschrieben, nimmt dieser Hook ein assoziatives Array aller gefundenen Migrationen als Argument. Sie können Migrationen ändern oder entfernen, die Sie nicht ausführen möchten.

Migrate Plus bietet das PREPARE_ROW-Ereignis

Wenn Sie Ihre benutzerdefinierten Antworten auf den Haupt-prepare_row-Handler lieber objektorientiert statt über hook_migrate_prepare_row() schreiben möchten, können Sie das mit dem aktivierten Modul Migrate Plus tun. Migrate Plus stellt das PREPARE_ROW-Ereignis bereit, an das sich Ihr Event-Subscriber anmelden kann. Weitere Informationen zur Event-Subscriber-Implementierung finden Sie im Beispiel des Simple FB Connect-Moduls.