Composer-gestütztes Upgrade von Drupal 8.x auf Drupal 9.x. Mit dem vorliegenden Drupal 9.1.5 sind die ärgsten Kinderkrankheiten ausgemerzt und es gibt keinen Grund, es länger aufzuschieben: Das Upgrade auf Drupal-9, um auf der Höhe der Zeit zu bleiben und man von den großartigen Neuerungen profitieren kann.
Vorbedingungen:
- Drupal Website mit letztgültiger Drupal-8 Version (derzeit 8.9.13)
- Drupal Website sollte mittels composer installiert sein
Projekt anlegen
Alle beschriebenen Arbeitsschritte werden in einer lokalen Entwicklungsumgebung durchgeführt. In einem frischen Projekt-Ordner diese Verzeichnisse anlegen:
assets
: Für Dinge wie Fonts, Layout-Bilder etc., die zur Website gehören, im Original-Zustandbackup
: Für Backups der Dateien und der Datebankconfig/sync
: Für Drupals Konfiguration, wenn man eingestellt hat, dass diese in Dateien anstatt in die Datenbank geschrieben werden sollenprivate
: Private Files. Im Gegensatz zu sites/default/files liegen hier Dateien mit Zugriffsberechtigung, falls man dies wünscht
All diese Dinge liegen "außerhalb des Web"; ein anonymer Besucher kann also nie auf diese Dinge zugreifen, indem er z.B. den Pfad errät.
Als Name für den Projekt-Ordner wähle ich persönlich einfach die Domain ohne Top-Level, aus domain.tld wird also der Projektordner domain. Das hat sich in der Praxis bewährt und es gibt kein Rätselraten, zu welchem Kunden "Projekt315" wohl gehören mag.
Auch in einer verteilten Arbeitsumgebung mit mehreren Leuten ist es wichtig, super-einfache Regeln aufzustellen, an die sich jeder hält und jeder sofort versteht.
Durch das Übertragen der Website-Bestandteile in eine frisch angelegte Datei-Installation hat man die Chance, Dinge zu entrümpeln und korrekt nach aktuellen Empfehlungen zu lösen.
Weist die Website-Struktur bereits die der empfohlenen Drupal-Installation auf, kann dieser Schritt auch übersprungen werden. Alle Websites, die zuvor nicht mit composer sondern per Direktdownload von drupal.org erzeugt wurden, sollten die Umstellung auf die neue Ordner-Struktur durchlaufen, sonst funktionieren auch die weiteren Schritte nicht.
Frisches Drupal-Projekt 8.x
Mittels
ein frisches Drupal-Projekt innerhalb des Projektordners anlegen. Falls diese Fehlermeldung erscheint...
... einfach ins Verzeichnis new_dir wechseln und mit composer update auf Stand bringen. Diese Fehlermeldung scheint daher zu kommen, dass composer selbst grade einen Versionssprung von 1.x auf 2.x hatte, so daß viele composer.json Dateien nicht mehr ganz aktuell sind.
Sobald composer mit dem Erzeugen fertig ist, kann der Inhalt von new_dir eine Ebene hochgeschoben und new_dir gelöscht werden.
Somit sieht der Projektordner nun wie folgt aus:
- .editorconfig
- .gitattributes
- assets/
- backup/
- composer.json
- composer.lock
- config/
- config/sync/
- private/
- vendor/
- web/
Website-Dateien umschieben
Die Bestandteile, die die Website ausmachen, aus dem alten Projektordner in den neuen schieben. Zu bewegen sind: files, theme(s), module, libraries und ggf. weitere Dinge wie favicons, spezielle .htaccess-Direktiven etc., z.B.
alter_ordner/sites/default/files --> projektordner/sites/default/files
Randnotiz Datei-Cache
Diese Verzeichnisse
- /sites/default/files/php
- /sites/default/files/css
- /sites/default/files/js
kann man gefahrlos löschen. Diese werden im laufenden Betrieb von Drupal automatisch angelegt und enthalten gecachte Dateien.
auch /sites/default/files/styles kann gefahrlos gelöscht werden. Hier werden die durch die Bildstile definierten Kopien der Original-Bilder abgelegt. Wenn hier etwas fehlt, wird es automatisch neu angelegt.
Gerade vor Übertragung oder dem Einpacken (zip, tgz, bzip, ...) sollte man daran denken, diese Verzeichnisse zu entsorgen, um die Dateigröße insgesamt klein zu halten.
Drupal Settings
Die Zugangsdaten zur Datenbank/Local und Datenbank/Hoster sollte man zur Hand haben, um die settings.php und settings.local.php zu erzeugen.
Gerade die settings.php ist eine sehr lange Datei mit sehr detaillierten Kommentaren als Hilfe zur Anwendung der verschiedenen Dinge in den Settings. Ich persönlich lösche alle Kommentare aus der settings.php und schiebe diejenigen Dinge, die Umgebungs-abhängig sind, in eine durch einen Kommentar abgetrennte Sektion.
Als Referenz zum Nachlesen der Einstellungsmöglichkeiten verbleibt default.settings.php.
Umgebungs-abhängig sind z.B. Datenbank-Verbindung, Fehleranzeige, Trusted Hosts und ggf. weitere.
In der settings.local.php verfahre ich ebenso. Die Umgebungs-abhängigen Dinge stehen unten in einem Segment zusammen. Mir erleichtert das die Übersicht und ich weiß, wo ich hinspringen muß, um etwas zu ändern. Ich muß nicht suchen.
Solange wir uns auf der lokalen Web-Umgebung bewegen, kommentieren wir die letzten Zeilen der settings.php Datei aus, damit settings.local.php geladen wird und aktiv ist.
In settings.php und settings.local.php nun auch die extra angelegten Verzeichnisse eintragen:
Diese hier nicht vergessen und entsprechend ihrer Umgebung in settings.php und settings.local.php entsprechende Werte eintragen:
Datenbank importieren
Mit einem Tool zur Datenbankverwaltung die Datenbank zur Website importieren und bereitstellen. Z.B. mit phpmyadmin, per Kommandozeile direkt mit SQL-Befehlen oder einem Programm mit GUI.
- DB-Tools im Webbrowser
- DB-Programme
- SequelPro (Mac OS)
- DBeaver (Mac OS, Win, Linux)
- MySQL Workbench
- TablePlus (Mac OS, Win, Linux)
Website prüfen
Website im Browser aufrufen. Je nachdem, wie die lokale Entwicklungsumgebung realisiert ist, mit vagrant, Docker, einem Virtualbox Image, homebrew, mampp, xampp o.a., differiert dies etwas.
In meinem Fall aktuell mit homebrew unter Mac OS X, dnsmasq/resolver, Apache 2.4 (homebrew) und MariaDB. Alle Web/Drupal Projekte liegen bei mir in einem Ordner sites auf einem NAS. Mittels dnsmasq/resolver aufgelöst und durch Apache ausgeliefert ergibt sich immer die Web-URL projektname.sites.test, was ich sehr praktisch finde.
Das Ablegen der Website-Dateien auf dem NAS ist nicht die schnellste Lösung, aber mir geht es primär um den Platz.
In einer Bearbeitungsschleife alle Fehler beheben; Warnungen können meist ignoriert werden.
Abschließend einem die Datenbank Aktualisierung durchführen, damit die Datenbank auch auf aktuellem Stand ist.
Upgrade Vorbereitung
Modul: upgrade_status
Quelle: https://www.drupal.org/project/upgrade_status
Das Modul aktivieren. Modul update_manager wird als Abhängigkeit mit aktiviert, falls inaktiv. Dieses Modul ist das Werkzeug für die Vorbereitung zum Upgrade.
Drupal-9 Tauglichkeit der Module
Schleife mit Prüfung der Drupal-9-Tauglichkeit aller vorhandenen Module der Website.
/admin/reports/upgrade_status aufrufen und einzelne Module updaten, falls möglich. Anderenfalls Deaktivieren/Deinstallieren.
Module, die auch nach einem Update auf die neueste Version nicht Drupal-9-ready sind, via Erweitern/Modul Deinstallieren entfernen. Nach Deaktivierung kann auch der zugehörige Modul-Ordner unter /modules gelöscht werden.
Das Upgrade ist auch eine Möglichkeit, ein bisschen aufzuräumen und nicht genutzte Module zu deaktivieren und zu löschen.
upgrade_status zeigt in tabellarischen Übersichten alle Module nach ihrem Status an. Man kann nun entweder alle Module, die nicht in Drupal 9 laufen werden, einzeln deinstallieren und löschen oder stumpf alle genannten Module mit composer require hinzufügen, um sie später mit composer remove zu entfernen. Das Ergebnis ist dasselbe.
Website Module updaten
Durch das Aufrufen von
ohne Versionsnummer wird automatisch die aktuellste Version, die auf drupal.org verfügbar ist, in die Datei composer.json eingetragen und installiert. composer lädt blitzschnell die Version gepackt herunter und entpackt den Modul-Ordner an die richtige Stelle (/modules/contrib). Es verbleiben keine Artefakte älterer Versionen desselben Moduls.
Um die vom gewünschten Modul abhängigen anderen Dinge kümmert sich composer automatisch und updated ggf. auch Dinge im /vendor Verzeichnis.
Anstatt jedes Modul einzeln anzufordern, kann auch eine lange Befehlszeile gebaut werden, mit der dann alles auf Schlag aktualisiert wird:
Website Theme "updaten"
Das genutzte Theme wird wahrscheinlich für Drupal-8 entwickelt worden sein. Hier muss eine entsprechende Zeile in die Datei /themes/custom/theme_name/theme_name.info.yml eingefügt werden:
am besten direkt nach dem core-Eintrag. Den Eintrag solchermaßen bearbeiteter Theme-Einträge in der Übersicht von upgrade_status markieren und "scannen" (Button ganz unten), damit diese Änderung übernommen und das Theme als Drupal-9-tauglich markiert wird.
Datenbank aktualisieren
Durch das Updaten der Module (genauer: der Dateien der Module) muß nun final auch nochmal die Datenbank auf Stand gebracht werden, hierzu einfach "Aktualisierungen durchführen" aufrufen.
Modul upgrade_status entfernen
Wenn die Status-Anzeige von upgrade_status 100% angzeigt und nun alle Module und Themes geprüft sind, als letzten Schritt das Modul upgrade_status deaktivieren und deinstallieren, es wird für die weiteren Schritte nicht mehr gebraucht.
Drupal 9 Upgrade durchführen
Quelle: https://www.drupal.org/docs/upgrading-drupal/upgrading-from-drupal-8-to-drupal-9-or-later
Jetzt geht es ans Eingemachte.
Dies aktualisiert erst die composer.json Datei, es passiert noch nichts. Erst wenn wir den nächsten Befehl ausführen lassen, sehen wir, ob alles geklappt hat.
Composer löst nun wieder alle Abhängigkeiten auf, lädt Fehlendes nach und ersetzt alte Bestandteile. Kurzum: Composer bringt unsere Website auf Drupal-9.
Der Prozess nimmt ggf. etwas Zeit in Anspruch; währenddessen kann man gespannt das Terminal beobachten, wie viele Zeilen dort vorbeirauschen. Oder man macht sich einen Kaffee.
Finaler Check der Website
Der nächste Aufruf von /admin/reports/status sollte nun anzeigen, dass hier eine Drupal-9 Version werkelt. Zum jetzigen Zeitpunkt ist es grad Drupal 9.1.5.
Nun noch ein Datenbankupdate via /update.php und diese Website ist auf Stand.
Anschließend kann diese Website deployed werden. Mit git, (s)ftp oder welche Möglichkeiten beim gewählten Hoster zulässig sind.
Kurzform für Copy-Paste im Terminal