Drupal - Upgrade 6 >> 7 Teil 1
Ab dem Zeitpunkt, wo Drupal 8 für den Produktiv-Einsatz frei gegeben wird, wird Drupal 6 nur noch für einen Zeitraum von ca. 6 Monaten weiter entwickelt.
D.h. Es gibt dann keine Sicherheits- und sonstige Updates mehr.
Deshalb sollte bereits jetzt eine Strategie überlegt werden, ob man Installationen unter Drupal 6 direkt auf 8 migriert oder Drupal 7 zwischen schaltet.
Komplexe Projekte mit vielen Modulen können kaum innerhalb des Zeitraums von sechs Monaten auf Drupal 8 migriert werden, da es voraussichtlich für viele Module noch kein Upgrade gibt.
Wir haben inzwischen zwei Projekte von Drupal 6 auf 7 migriert.
Das eine war bereits vor zwei Jahren eine eigene Installation.
Über dieses Upgrade haben wir im Zusammenhang mit Bildern schon mal berichtet:
http://www.montviso.de/blog/nachbau-einer-drupal-6-bildergalerie-nach-dem-upgrade-auf-drupal-7
Über das zweite – soeben abgeschlossene – Upgrade berichten wir hier, und greifen beispielhaft einige der typischen Stolpersteine heraus bzw. skizzieren den Ablauf (ohne Anspruch auf Vollständgkeit).
Ergänzungen via Kommentar sind willkommen.
Bitte beachtet, daß jede Drupal-Installation sehr individuell ist und folglich auch ganz andere Probleme auftreten können.
Drupal - Upgrade 6 > 7 Teil 1 (Rolf Schosser)
Drupal - Upgrade 6 > 7 Teil 2 (Regina Oswald)
Drupal - Upgrade 6 > 7 Teil 3 (Regina Oswald)
1. Aufwandschätzung:
Im ersten Schritt wird das bestehende System analysiert.
Dazu wird geprüft, welche Comunity-Module und welche Custom-Module (Eigenentwicklungen) eingesetzt werden.Für die Comunity-Module wird die Verfügbarkeit unter Drupal 7 nach geschlagen.
Evt. Sind sie ins Core übernommen worden, dann sind die unkritisch.
Falls sie nicht in Version 7 vorliegen, kann man grob schätzen, ob es Alternativen gibt.
Eigenentwicklungen werden analysiert auf Umfang und Einsatz von API-Funktionen, die evt. Migriert werden müssen.
Die Module Diff und Hacked sind hilfreich, um evt. Code-Änderungen am Core und in Comunity-Modulen aufzuspüren. Diese sind gesondert zu betrachten.
Als nächstes wird untersucht, ob ein selbst geschriebenes Theme im Einsatz ist, oder das Subtheme eines regulären Drupal-Themes.
Ein Blick in das Theme gibt Aufschluss darüber, wie viele Code-Anpassungen in der Datei template.php bzw. in View- / Node-Templates vorgenommen wurden und wie groß der Anpassungsbedarf in diesen ist.
Auch sieht man, ob zusätzliche JavaScript-Dateien eingebunden sind.
Bei der Gelegenheit ist im Aufwand zu werten, ob das Theme mobile-fähig ist oder ob ein moderneres Theme zum Einsatz kommen sollte.
Oft werden solche Upgrades ja auch für einen kompletten Relaunch genutzt, das ist aber ein adneres Thema.
Es sollte auch die PHP-Version überprüft werden.
Drupal 7-Module benötigen eine neuere Version, möglicherweise laufen aber die alten drupal 6 Module nicht mit der neuen PHP-Version.
Das Vorgehen für die Livestellung am Stichtag mit Aktulaisierung von Inhalten, die während der Arbeit an der Upgrade-Version auf dem Livesystem gemacht wurden, sollte gesondert betrachtet werden.
Je mehr Interaktion mit Usern (evt. Auch anonymen Usern) desto genauer muß hier geplant und Aufwand geschätzt werden, damit die User-Accounts, Kommentare, Bewertungen, Flags ect. nach der Migration aktuell sind.
Im Aufwand besonders zu berücksichtigen ist die Anpassung einer evt. Simplenews Installation.
Dieses Modul wurde komplett neu geschrieben.
2. Vorbereitung
Idealerweise wird ein Backup der Drupalversion als Sub-Domain eingerichtet, auf der evt. Hilfsprogramme installiert werden können (Feeds-Importer), zusätzliche Views für Daten-Export ect.
Zusätzlich wird das Backup unter einer zweiten Subdomain eingerichtet. Dieses wird der Ausgangspunkt unserer künftige Drupal 7 Testversion.
Wir verwenden für Backups der Datenbank das Programm MySqlDumper:
3. Drush-Upgrade
Drush ist ein Kommandozeilenprogramm für Drupal, das manche Dinge wesentlich vereinfacht.Um drush zu nutzen, braucht man eine SSH-Verbindung mit dem Hoster. Dafür kann man PuTTY verwenden.
Voraussetzung für das Upgrade mit Drush ist eine funktionierende Drush-Installation. Dokumentation zur Drush-installation befindet sich beispielsweise hier: http://docs.drush.org/en/master/install/ und hier: https://www.drupal.org/node/1791676
Von Drush gibt es mehrere Versionen, von denen jede mehrere Drupal-Versionen supportet. Ich habe Drush 6.4.0 verwendet.
Für das Upgrade von Drupal 6 auf Drupal 7 verwenden wir den Befehl site-upgrade. Dieser Befehl ist in Drush 6 nicht standardmässig vorhanden und muss extra installiert werden https://www.drupal.org/project/drush_sup
Damit drush Fehler anzeigt, aber nicht automatisch abbricht, muss folgendes gemacht werden: Datei sites/all/drush/drushrc.php
$options['strict'] = 0
Bevor wir mit dem upgrade anfangen, muss zuerst unsere Drupal 6 -Seite auf die neueste Drupal-6 Version von core und Modulen gebracht werden. Dazu verwenden wir der Einfachheit halber ebenfalls drush mit
drush pm-update.
Damit sind wir vorbereitet.
Drush site-upgrade macht eine Kopie der Seite, auf der ich das Upgrade ausführe und lässt die bestehende Installation unangetastet. Das Zielverzeichnis für die Kopie muss vorhanden sein, ebenso wie eine leere Datenbank für die Neuinstallation. Ausserdem ist ein drush-alias für das Zielverzeichnis hilfreich. Ich wechsle in das Drupal-Root-Verzeichnis in der Subdomain, die ich als Ausgangspunkt eingerichtet habe und rufe
drush site-upgrade @zielverzeichnis
auf.
Es kommen dann verschiedene Optionen zurAuswahl, ob ich ein Backup verwenden will oder ganz von vorn anfange etc. Wir wählen 'start up from the beginning'.
Site-upgrade sammelt im nächsten Schritt Informationen über die bestehende Installation, dh. es checkt die Core-Version und die Drupal 7-Verfügbarkeit der installierten Module.
Es wird eine Liste der installierten Module und ihrer Drupal 7-Versionen ausgegeben.
Wenn wir Glück haben, gibt es für alle unserer Module eine höhere Version.
Falls es keine Drupal 7 Version gibt, schlägt site-upgrade mögliche Alternativen vor und wenn es gar nichts gibt, steht
'NO 7.x RELEASES' da.
Pech, da kommt dann die schöne Meldung
'Based on the contrib modules enabled in this site, it is possible that the site-upgrade command might fail. See warnings above.'
Und wir bekommen zur Auswahl:
'Please review the upgread readiness report. You may want to uninstall modules that are not ready to upgrade yet.
Cancel
Begin upgrade'
Es hat keinen Sinn, das Upgrade an dieser Stelle zu beginnen, denn das endet mit Fehlern. Wir brechen daher an dieser Stelle ab und deaktivieren erst einmal die angemerkten Module.
Bei mir hat deaktivieren gereicht, deinstallieren musste ich keines.
Wenn alle Module, für die es Warnungen gab, deaktiviert sind, macht man die Schritte bis zum Statusreport nochmals und prüft im neuen Statusbericht, wie es nun aussieht.
Wenn alles OK erscheint, beginnt das Upgrade.
Es erfolgen nun eine ganze Reihe Meldungen, bei denen nichts Wesentliches passiert und man nur zuschauen kann.
Drush lädt uns die neueste Drupal 7-Version ins das Zielverzeichnis.
Als nächstes wird man aufgefordert, Änderungen an der .htaccess und der robots.txt nachzuziehen.
Es empfiehlt sich, das zu tun.
Drush schreibt nun eine neue settings.php, kopiert die Drupal-6-Datenbank in die neue Datenbank, disabled sämtliche Module, setzt das Thema auf Garland und das Admin-Theme auf seven.
Dann versucht drush, update.php aufzurufen. Wenn das scheitert, müssen wir in der settings.php
$update_free_access = TRUE;
setzen. Das wird nach dem erfolgten Update unbedingt wieder auf False gesetzt.
Im weiteren Verlauf kommen eine Menge Meldungen, Warnings und Errors eingeschlossen. Das endet mit der Präsentation einer Liste von Modulen, die für das Upgrade bereit sind. An dieser Stelle muss wieder einmal gewählt werden, ob man weitermacht oder abrricht.
Es empfiehlt sich unbedingt, erst die Errors und Warnings zu bearbeiten, bevor man nun fortsetzt. Es kann z.b sein, dass kein sites/default/files/tmp-Verzeichnis vorhanden ist, ich musste auch die Tabellenspalten locales_source.source und locales_target.translation von BLOB auf MEDIUMBLOB ändern. Da gibt es sicher auch noch andere mögliche Fehler.
Man steht dann bei einer Meldung, die heisst 'Please select a module to upgrade, or some other action below:', an dieser Stelle kann man einzelne Module oder alle auf einmal für das Upgrade auswählen. Drush lässt dann diese Upgrades durchlaufen. Das dauert eine ganz Weile.
Ein paar Module können wahrscheinlich nicht upgegraded oder enabled werden und müssen je nach Fehlermeldung gesondert behandelt werden. Möglicherweise müssen Tabellen umbenannt oder Module durch andere Versionen als die automatisch von drush gewählte Version ersetzt werden, was z.B bei currency_api der Fall war. Andere Module müssen an dieser Stelle einfach disabled bleiben und damit beschäftigen wir uns später.
Falls man von seinem Theme eine Drupal 7 -Version hat, dann kopiert man es in den themes.ordner und enabled es. Das muss händisch gemacht werden. Ebenso wird der Drupal 6 files-Ordner händisch in die Drupal 7- Version kopiert.
Drush fragt an dieser Stelle, ob es den Content migrieren soll, und wenn wir das bestätigen, führt es alle verfügbaren Migrationen durch.
Zum Schluss müssen eventuell verschiedene Dateisystem-Berechtigungen neu gesetzt werden. Gegen Ende führt drush noch einen Cron-Lauf durch und gibt einen Statusreport aus, damit wir uns die Einstellungen ansehen können. Dann werden wir noch aufgefordert, update_free_access in der settings.php auf FALSE zu setzen, Drupal stellt die Seite online und wir machen uns händisch an die Feinheiten.