Bekannte Probleme beim Upgrade von Drupal 6 oder 7 zu Drupal 8

Drupal 6 bis 8

Aggregatorkategorien

In Drupal 8 gibt es das Konzept der Aggregatorkategorien nicht mehr, daher werden sie nicht nach Drupal 8 migriert.

Zugelassene Protokolle

Drupal 8 speichert die Protokolle jetzt im Containerparameter „filter_protocols“. Wenn Sie die Variable „filter_allowed_protocols“ geändert haben, geben Sie diese in der Datei services.yml ein.

Zugelassene Vokabulare des Taxonomie-Referenzfeldes

In Drupal 6 ist die Liste der anwendbaren Inhaltstypen für ein bestimmtes Vokabular in den Einstellungen des Vokabulars definiert. In Drupal 8 können zugelassene Vokabulare in den Einstellungen des Taxonomie-Begriffreferenzfeldes definiert werden. Diese Einstellung wird derzeit nicht migriert, wodurch in Drupal 8 auf alle Vokabulare verwiesen werden kann. Sie können die Einstellungen des Taxonomie-Begriffreferenzfeldes in Drupal 8 nach dem Upgrade manuell bearbeiten und die zugelassenen Vokabulare auswählen.

[Behoben] Datumsformate

Nur die Standardformate „kurz“, „mittel“ und „lang“ werden migriert. Alle anderen Standardformate haben ein Backup-Format und müssen nach der Migration neu konfiguriert werden.

Felder, die im Bearbeitungsformular oder auf der Ansichtseite fehlen

Ein weiteres verwirrendes Problem ist, wenn Sie eine scheinbar erfolgreiche Migration durchführen, danach Ihre Felder aber nicht im Bearbeitungsformular sehen. Gehen Sie auf die Seite zur Verwaltung der Inhaltstypen und öffnen Sie die Registerkarte „Formularanzeige verwalten“ für jeden Inhaltstyp. Felder, die durch das Upgrade hinzugefügt wurden, können im Bearbeitungsformular ausgeblendet sein. Ziehen Sie sie hoch, damit sie sichtbar sind. Ebenso, wenn sie in der Node-Ansicht nicht erscheinen, könnten die durch Migrate hinzugefügten Felder auf der Registerkarte „Anzeige verwalten“ versteckt sein, und Sie müssen sie dort sichtbar machen. Beim Migrieren benutzerdefinierter Felder kann das Modul Migrate Plus hilfreich sein.

Startseite lädt, aber Thema funktioniert nicht

Manchmal zeigt die Seite nach der Migration nur eine weiße Seite mit wenigen geladenen Elementen – wie ein defektes Theme. Der Besuch von /user und die Rückkehr zur Startseite lösen das Problem meist.

Menü-UI

Die Variablen menu_primary_links_source und menu_secondary_links_source werden nicht migriert, da es keine Entsprechungen in Drupal 8 gibt.

Module und Themes

Bevor Sie mit der Migration beginnen, müssen Sie neue Module und Themes aktivieren und ggf. das Admin-Theme setzen.

Inhaltstypen (Nodes)

Die Standardkonfiguration in Drupal 6 enthält die Inhaltstypen Story und Page. Die Standard-Inhaltstypen in Drupal 8 heißen Article und Basic Page (letzterer hat den maschinellen Namen 'page', wie in Drupal 6).

• Die Migration ordnet den Drupal-6-Inhaltstyp „Page“ dem Drupal-8-Inhaltstyp „Page“ zu, da die maschinellen Namen übereinstimmen.
• Für Drupal 8 wird der Inhaltstyp Story neu erstellt. Eventuell möchten Sie den Inhaltstyp Article in Drupal 8 löschen, wenn Sie ihn nicht benötigen. Weitere Informationen finden Sie unter #2236289: Migration von „Story“-Nodes aus D6 erzeugt neuen Inhaltstyp in D8.

Node-Übersetzungen

In Drupal 6 und 7 wurden Node-Übersetzungen als separate Nodes gespeichert, während sie in Drupal 8 mit ihren Original-Nodes zusammengeführt werden. Das Migrationssystem führt die Zusammenführung durch, was bedeutet, dass einige Links nun auf nicht mehr existierende Nodes verweisen könnten. Siehe #2746527: [META] Verarbeitung von Drupal 6 und 7 Node-Übersetzungsdaten mit verschiedenen IDs.

Node-Revisionen von übersetzten Nodes sind noch nicht migriert. Siehe #2746541: [Backport] Migration von D6/D7 Node-Revisionen nach D8 für Details.

Übersicht zum Upgrade von mehrsprachigem Drupal 6 auf Drupal 8.

Profilkategorien

Felder, die im Drupal-6-Profil-Modul gruppiert sind, werden in Drupal 8 nicht gruppiert.

Profilfeld (Auswahlliste)

Die Einstellung der „zugelassenen Werte“ des resultierenden Feldes in Drupal 8 ist eine Kombination aus allen benutzerdefinierten ausgewählten Werten und den aktuellen zulässigen Werten in Drupal 6, nicht nur der zulässigen Werte in Drupal 6.

Statistiken

Zugriffsprotokoll- und Statistik-Einstellungen werden nicht i18n-migriert. Die Konsolidierung i18n-statistischer Daten wurde ab Drupal 8.5.2 migriert. Siehe #2930101: i18n/statistics – Node-Counter wird für Übersetzungen nicht aktualisiert.

Text-/Eingabeformate

Filterformate, die Drupal 8 nicht erkennt, werden als filter_null migriert, ein Filter, der einfach einen leeren String zurückgibt. Das bedeutet, dass jedes Eingabeformat, das einen unbekannten Filter verwendet, den Feldinhalt nicht anzeigt, obwohl die Inhalte in der Datenbank vorhanden sind. Das kann verwirrend sein. Siehe #2618332: Bessere Behandlung fehlender Filterersatz mit filter_null und #2630578: Doppelte Formate beim D6-Upgrade.

Zu den nicht erkannten Filterformaten zählen der berüchtigte PHP-Code-Filter sowie alle weiteren Filter von Contributed-Modulen, die in Ihrer Drupal-8-Installation nicht verfügbar sind.

Der PHP-Filter wird im Drupal-8-Core nicht unterstützt – das ist sehr schlechte Praxis –, aber Sie können das PHP-Modul verwenden, falls es wirklich nötig ist.

Um das zu beheben, haben Sie mehrere Möglichkeiten:

• Prüfen Sie, ob Module, die Filter bereitstellen, eine Drupal-8-Version haben, und installieren Sie diese.
• Bearbeiten und speichern Sie die betroffenen Eingabeformate neu. Dadurch wird die Referenz auf filter_null entfernt, und die Inhalte werden angezeigt. Beachten Sie, dass der ursprüngliche Filter nicht existiert, Inhalte daher nicht gefiltert werden, ersetzte Tokens sichtbar sein können oder die Seite Sicherheitsprobleme haben könnte.
• Bearbeiten Sie die Inhalte und ändern Sie das Eingabeformat auf ein anderes. Das hat dieselben Probleme wie der vorherige Punkt.

Zeitzonen und Daten

Drupal 6 verwendet eine Zeitzonenverschiebung zur Berechnung der Ortszeit. Drupal 7 und Drupal 8 verwenden den Zeitzonennamen. Leider generiert die PHP-Funktion timezone_name_from_abbr(), die eine Verschiebung in Zeitzonennamen umwandelt, je nach Sommerzeit-Einstellung Ihres Servers unterschiedliche Namen. Zum Beispiel wird die Verschiebung 3600 zu Europe/Paris, wenn die Sommerzeit deaktiviert ist, und Europe/London, wenn die Sommerzeit aktiviert ist. Die Migration ist so konzipiert, dass sie die Sommerzeit ignoriert. Je nach Serverkonfiguration kann die Zeitzoneneinstellung in Drupal 8 nach der Migration falsch sein (#2353679: Fehlende Variable migration D6->D8: date_default_timezone).

In Zeitzonen mit Sommerzeit kann Drupal 8 Daten anders interpretieren als Drupal 6. Zum Beispiel könnte ein Datum nahe Mitternacht als ein anderer Tag angesehen werden. Das führt zu Problemen, insbesondere wenn Datums-Token für Pfade verwendet werden (z. B. URL-Alias, Dateipfadfelder). Zwei mögliche Lösungen finden Sie unter #2926421: Umgang mit Datumsinkonsistenzen zwischen D6 und D8.

URL-Aliase

Wenn URL-Aliase für eine Sprache migriert werden, die auf der neuen Drupal-8-Seite nicht aktiviert ist, funktionieren keine Aliase, bis die Sprache aktiviert wird.

Views

Views werden noch nicht migriert, Sie müssen sie in Drupal 8 manuell neu erstellen. Weitere Informationen finden Sie unter #2500547: Upgrade-Pfad für Views aus Drupal 6 und 7 und dem Modul Views Migration.

Benutzeraktivitätsblock-Konfiguration

Benutzeraktivitätseinstellungen werden nicht migriert. Diese müssen manuell im entsprechenden View im Bereich Filter/Zugriff bearbeitet werden (#2169327: Benutzeraktivitätsblock-Konfiguration migrieren).

Drupal 7 bis 8

[Behoben] Zugelassene Taxonomie-Vokabulare

In Drupal 7 wird das zugelassene Vokabular für das Taxonomie-Begriffreferenzfeld in dessen Einstellungen definiert. Diese Einstellung wird derzeit nicht migriert, sodass in Drupal 8 auf alle Vokabulare verwiesen werden kann. (Siehe #2763637: D7 Taxonomie-Term-Felder migrieren nicht mit zugelassenen Vokabularen). Sie können die Einstellungen des Taxonomie-Begriffreferenzfeldes in Drupal 8 nach dem Upgrade manuell bearbeiten und die zugelassenen Vokabulare auswählen.

Gesperrte IP-Adressen

Die Spalte „id“ aus der Tabelle ban_ip in Drupal 7 wird nicht migriert.

Kommentar-Typen

Drupal 7 erlaubt es, für Kommentare unterschiedliche Felder je nach Inhaltstyp zu haben. Normalerweise haben Kommentare die Felder Autor, Betreff und Kommentar. Da unterschiedliche D7-Kommentare verschiedene Felder haben können, werden für jeden Inhaltstyp in Drupal 8 separate Kommentar-Typen erstellt:

• Der Inhaltstyp Foo erhält den Kommentar-Typ comment_node_foo
• Der Inhaltstyp Bar erhält den Kommentar-Typ comment_node_bar

Die einzige Ausnahme sind Forenkommentare. Wenn das D8-Forum-Modul aktiviert ist, wird automatisch der Kommentar-Typ comment_forum erstellt. D7-Forumskommentare werden in diesen Kommentar-Typ migriert.

Wichtig: Standard-Installationsprofil von Drupal 8 und Inhaltstyp „Article“
Wenn Ihre Drupal-8-Seite mit dem Standard-Installationsprofil eingerichtet wurde, haben Sie den Inhaltstyp Article.

• Dieser Inhaltstyp verfügt über ein Kommentarfeld namens „Kommentar“.
• Das Migrationssystem kann nicht annehmen, dass die D8-Seite mit dem Standardprofil installiert wurde. Deshalb wird der Kommentar-Typ comment_node_article erstellt, und D7-Artikelkommentare werden diesem Kommentar-Typ zugewiesen.

Als Ergebnis hat Ihr Inhaltstyp Article jetzt zwei Kommentarfelder:

• Kommentar, vom D8-Standardprofil, das aber nicht genutzt wird
• comment_node_article, vom Migrationssystem erzeugt

Wahrscheinlich möchten Sie nicht zwei Kommentarfelder für Article haben, daher sollten Sie das Kommentarfeld „Kommentar“ aus Article (admin/structure/types/manage/article/fields) manuell entfernen. Danach können Sie den Kommentar-Typ „Kommentar“ (admin/structure/comment) entfernen, falls er nirgendwo verwendet wird.

Es wird empfohlen, das unnötige Kommentarfeld vor der Migration zu entfernen, da Drupal 8 derzeit einen Fehler beim Entfernen von Kommentarfeldern hat. Siehe #2906470: Verlorene Kommentare und Einträge in comment_entity_statistics nach Entfernen einer Kommentarfeld-Instanz.

PHP-Code

Filterformate, die Drupal 8 nicht erkennt, werden als filter_null migriert, ein Filter, der einen leeren String zurückgibt. Das bedeutet, dass Eingabeformate mit unbekannten Filtern keine Feldinhalte anzeigen, obwohl die Inhalte in der Datenbank vorhanden sind.

Zu den nicht erkannten Filtern gehört der berüchtigte PHP-Code-Filter sowie alle anderen Filter aus Contributed-Modulen, die in Ihrer Drupal-8-Installation fehlen.

Der PHP-Filter wird im Drupal-8-Core nicht unterstützt, da es schlechte Praxis ist, aber Sie können das PHP-Modul verwenden, wenn es wirklich nötig ist.

Sie haben mehrere Optionen, um dies zu beheben:

• Prüfen Sie, ob die Module mit den Filtern eine Drupal-8-Version haben und installieren Sie diese.
• Bearbeiten und speichern Sie die betroffenen Eingabeformate erneut. Dadurch wird die Referenz auf filter_null entfernt und der Inhalt wird angezeigt. Beachten Sie, dass Inhalte dann nicht gefiltert werden, nicht ersetzte Tokens sichtbar sein können oder Sicherheitsprobleme auftreten können.
• Bearbeiten Sie die Inhalte und ändern Sie das Eingabeformat zu einem anderen. Das hat dieselben Probleme wie der vorherige Punkt.

Plain-Text-Felder

Widersprüchliche Textverarbeitungs-Einstellungen in Drupal 7
In Drupal 7 werden die Textverarbeitungsoptionen auf Feldebene konfiguriert. Das heißt, dass dasselbe Feld für mehrere Inhaltstypen verwendet werden kann, mit unterschiedlichen Textverarbeitungsoptionen wie „Plain Text“ für einen Typ und „Gefilterter Text“ für einen anderen.

Drupal 8 hat separate Feldspeichertypen für Text (Plain) und Text (Formatiert). Es gibt auch Text (Plain, lang) und Text (Formatiert, lang). Entscheidend ist, dass die Auswahl auf der Speicherebene im Feld erfolgt. Das bedeutet, dass plain/formatierte Auswahl nicht pro Inhaltstyp geändert werden kann.

Das Migrationssystem trifft keine Annahmen. Wenn es widersprüchliche Textverarbeitungsoptionen findet, überspringt es diese Felder mit einem Logeintrag. Der Sitebuilder hat zwei Optionen:

1. Ändern Sie die Textverarbeitungsoptionen auf der Drupal-7-Seite so, dass alle Inhaltstypen, die das Textfeld verwenden, dieselben Einstellungen haben.

• Achten Sie darauf, mögliche Cross-Site-Scripting (XSS) Sicherheitsprobleme zu vermeiden.
• Wenn Ihr Feld in Drupal 7 als „Plain Text“ definiert ist und unzuverlässige Benutzer Inhalte in das Feld eingeben konnten, könnten diese Felder schädlichen Code enthalten. Das führte in Drupal 7 nicht zu XSS, weil es als Plain Text gespeichert wurde und somit nicht ausgeführt wurde. Wenn Sie das Feld nun auf Gefilterten Text ändern, stellen Sie sicher, dass das Textformat kein vollständiges HTML oder ähnliches ist, das schädlichen Code zulassen würde.

2. Wenn Sie zwei unterschiedliche Formatierungen in Drupal 8 benötigen, müssen Sie eine eigene Migration schreiben, die das Drupal-7-Feld in zwei separate Drupal-8-Felder aufteilt. Weitere Informationen zum Anpassen von Migrationen beim Upgrade finden Sie hier: Migrationen beim Upgrade auf Drupal 8 anpassen.

Zusammenfassungstext + Plain-Text-Formatierung in Drupal 7
Drupal 7 hat den Feldtyp Long text and summary. Der entsprechende Feldtyp in Drupal 8 ist Text (formatiert, lang, mit Zusammenfassung). In Drupal 7 kann in den Feldeinstellungen festgelegt werden, dass die Textverarbeitung Plain Text ist. Text (formatiert, lang, mit Zusammenfassung) ist in Drupal 8 immer formatiert.

Das Migrationssystem trifft keine Annahmen. Wenn es Felder mit Long text und Zusammenfassung und Plain-Text-Verarbeitung findet, überspringt es diese mit Logeintrag. Sitebuilder haben die gleichen zwei Optionen wie oben:

1. Ändern Sie die Feldformatierung von Plain Text auf Gefilterten Text in Drupal 7.

• Die oben genannten XSS-Hinweise gelten hier ebenso.

2. Schreiben Sie eine eigene Migration mit eigener Logik, wie die Felder in Drupal 8 übertragen werden sollen. Mehr dazu siehe: Migrationen beim Upgrade auf Drupal 8 anpassen.

Statistiken

Zugriffsprotokoll- und Statistik-Einstellungen werden nicht i18n migriert. Die Konsolidierung i18n-statistischer Daten wurde ab Drupal 8.5.2 migriert. Siehe #2930101: i18n/statistics – Node-Counter wird für Übersetzungen nicht aktualisiert.

Views

Views werden noch nicht migriert, Sie müssen sie in Drupal 8 manuell neu erstellen. Weitere Informationen finden Sie unter #2500547: Upgrade-Pfad für Views aus Drupal 6 und 7 und dem Modul Views Migration.

Potenzielle ID-Konflikte (von D6 oder D7 zu Drupal 8)

Problem

Wie auf der Seite Vorbereitung auf ein Upgrade beschrieben, sollte die Drupal-8-Site beim Upgrade vollständig leer sein. Der Migrationsprozess behält die IDs der Quellseite bei, wenn diese in die Drupal-8-Seite importiert werden. Wenn Inhalte auf der Drupal-8-Site vor dem Upgrade erstellt wurden (z. B. Node mit nid 1), besteht eine hohe Wahrscheinlichkeit von ID-Konflikten.

Es wird derzeit an der automatischen Erkennung potenzieller ID-Konflikte und Benutzerwarnungen gearbeitet, siehe #2876085: Überprüfung potenzieller ID-Konflikte vor Upgrade. Derzeit müssen Site-Administratoren mögliche Konflikte selbst sorgfältig prüfen. Werden ID-Konflikte nicht vorsichtig behandelt, können Inhalte oder andere Entitätselemente wie Taxonomiebegriffe und Dateien überschrieben werden, was Datenverlust bedeutet. Auch Referenzobjekte können beschädigt werden, z. B. kann Inhalt falschen Taxonomiebegriffen zugewiesen werden.

Szenarien, die ID-Konflikte verursachen können

• Die Ziel-Drupal-8-Seite wurde bereits vor dem Upgrade genutzt und es wurde Inhalt erstellt.
• Die Erstmigration wurde abgeschlossen. Nach der Erstmigration wurden Inhalte oder Objekte auf Quell- und Zielseiten erstellt. Wenn dann erneut migriert wird, können IDs mit bereits auf der Drupal-8-Seite erstelltem Inhalt kollidieren.
• Die Drupal-8-Zielseite war frisch, aber aktivierte oder benutzerdefinierte Module haben eigene Daten hinzugefügt. Zum Beispiel erzeugt das Drupal-8-Forum-Modul einen Taxonomiebegriff für die Kategorie „Allgemeine Diskussion“, der in einer neuen Installation meist die ID #1 erhält. Wenn die Quelldaten einen Taxonomiebegriff mit ID 1 enthalten, überschreibt dieser den Namen der allgemeinen Diskussionskategorie.
• Die Quelle hat Daten ohne ID, das Ziel verlangt jedoch eine ID. Beispiel: Drupal 6 behandelt Benutzerbilder als unmanaged Dateien ohne ID, Drupal 8 verlangt jedoch verwaltete Dateien mit ID. Bei der Migration werden verwaltete Dateien mit IDs erstellt, die mit noch zu migrierenden Dateien kollidieren können.
• Mögliche ID-Konflikte bei Übersetzungen werden derzeit nicht automatisch erkannt.