You are here

Von Drupal 5 nach Drupal 6 - eine Schritt-für-Schritt-Anleitung

Eine Website von Drupal 5 auf die Version 6 umzustellen, ist eigentlich gar nicht so schwer - sofern man ein paar wichtige Dinge beachtet. Im folgenden beschreibe ich die Umstellung einer etwas größeren Community-Seite, auf der neben dem Core-Drupal noch diverse Contributed Modules liefen.Wichtig für den Erfolg ist eine gründliche Vorbereitung. Die eigentliche Umstellung ist dann an einem Tag zu schaffen. Wenn, wie hier, noch ein aufwändiges Layout dazukommt, geänderte URLs umgeleitet werden sollen und neue Funktionen hinzukommen, sollte man aber doch lieber mal ein komplettes Wochenende dafür einplanen. 

Und so haben wir es gemacht:

Schritt 1: Dokumentation lesen! Da wäre zum einen die offizielle Doku für Drupal http://drupal.org/upgrade oder natürlich diese Anleitung hier.

Schritt 2: Backup der Datenbank und des kompletten Verzeichnisses mit allen Dateien. Aber das ist sicher für alle selbstverständlich, oder?! Darüber hinaus empfiehlt es sich zwischen den einzelnen Arbeitsschritten immer mal wieder ein Backup der Datenbank durchzuführen. Am einfachsten geht das - vor allem wenn die Datenbank etwas größer ist - mit MySQLdumper. Wie das geht habe ich in diesem Artikel beschrieben.

 
Schritt 3: als User 1 einloggen (falls man das nicht ohnehin schon ist)

Schritt 4: Bestandsaufnahme der vorhandenen Module.

 
Hilfreich für diese Bestandsaufnahme sind die Module Upgrade Status - das ergänzt Update Status und zeigt an, für welche Module es Nachfolge-Versionen gibt und welchen Status diese haben (also bereits stable oder noch dev).

Für Module für die es noch kein Upgrade gibt, muss Ersatz oder ein Workaround her. Ein Beispiel ist Workflow-NG. Dafür gibt es nicht direkt eine D6-Version, aber einen Nachfolger namens Rules, der wohl auch viele Workflow-NG-Regeln übernehmen kann. In unserem Fall gab es nur zwei Module, für die es keine 6er-Version gab und die daher durch Alternativen ersetzt werden mussten: Node Profile und Node Family. Als nächstes lädt man alle benötigten Module herunter damit sie für das Upgrade bereit stehen. Außerdem sollte man bei der Gelegenheit auch schauen, ob es nicht Module gibt, die mittlerweile überflüssig geworden sind. Gerade bei Installationen, die schon längere Zeit laufen, wurde vielleicht schon das eine oder andere Modul als entbehrlich deaktiviert oder durch ein anderes ersetzt - ohne dass es vollständig deinstalliert wurde. Aber es gibt auch Funktionen die Drupal 6 mittlerweile mitbringt, so dass Zusatz-Module hierfür überflüssig geworden sind.

 
Schritt 5: überflüssige Module deinstallieren. Warum was upgraden, was man nicht (mehr) braucht?

Schritt 6: Website offline schalten. Ab jetzt ist die Seite nur noch für den User 1 zugänglich. Normale Besucher bekommen die Wartungsseite angezeigt. Deren Text sollte man vorher entsprechend anpassen - der normale Wartungshinweis ist hier eher unpassend.
 
Schritt 7: Update von Drupal 5 und aller Module, die auch auf Drupal 6 laufen sollen, auf die jeweils neueste (stable) 5er-Version (5 nicht 6 - dieser Schritt kommt später!)

Schritt 8: Auf ein Drupal-Standard-Theme (z.B. Garland) umschalten. Bevor man das Theme umschaltet sollte man sich vergewissern, dass der Block mit dem Navigationsmenü in diesem Theme sichtbar ist. Da Blöcke Theme-spezifisch eingeblendet werden, kann es sonst passieren, dass man plötzlich keinen Admin-Block mehr hat.

Schritt 9: Nun deaktivert man alle Nicht-Core-Module. Das geht in der Regel nur in mehreren Schritten, da Module mit Abhängigkeiten u.U. erst deaktiviert werden können, wenn ein von ihm abhängiges ausgeschaltet wurde.

Schritt 10: Als nächstes löscht man alle Drupal-Dateien vom Server (Backup auch nicht vergessen?). Das gilt auch für die Dateien im Webserver-Root-Verzeichnis und für alle Unterverzeichnisse. Nun lädt man die aktuelle Drupal6-Version hoch. Anschließend werden die Verzeichnisse ../files und - falls vorhanden - Domain-spezifische Unterordner von ../sites wieder angelegt und in ../files die alten Inhalte zurück gespielt. In den Dateien settings.php, .htaccess und robots.txt werden nun noch die ursprünglichen Modifikationen wieder eintragen - bei settings.php insbesondere die Zugangsdaten zur Datenbank, etwaige multilinguale Variablen oder shared Tables einer Multisite-Installation. Außerdem noch die Zeile ergänzen $update_free_access = TRUE;

Achtung: das Unterverzeichnis ../sites/modules darf nicht mehr die alten D5-Module enthalten, bevor wir mit dem nächsten Schritt fortfahren!
Wer ein eigenes Theme für die Seite benutzt spielt auch dieses jetzt ein. Wie üblich kommen eigenen Themes in den Ordner ../sites/all/themes.

Schritt 11: Nun wird die update.php (http://meine-domain.xy/update.php) ausgeführt. Sollten hierbei Fehler auftreten, notiert man diese. In der Regel genügt ein erneutes Ausführen von update.php, um sie verschwinden zu lassen. Achtung: es dürfen zu diesem Zeitpunkt noch keine contributed Modules aktiviert sein!

Schritt 12: Jetzt geht es an das Upgrade der Contributed Modules. Dabei unbedingt die speziellen Upgrade-Instruktionen für bestimmte Module beachten (z.B. CCK). Sobald man ein Modul aktiviert hat sollte man erneut update.php laufen lassen, so lässt sich leichter ermitteln welches Modul eventuell Probleme bereitet, als wenn man mehrere auf einen Schlag aktiviert.

Spezielle Upgrade-Instruktionen für einzelne Module.

Die folgenden Module hatten spezielle Anweisungen für ein Upgrade von Drupal 5 auf 6: CCK, Views und Rules (siehe auch Schritt 14).
 
CCK
 
UPDATING FROM VERSION 5.x to 6.x

YOU MUST RUN ALL POSSIBLE UPDATES TO YOUR DATABASE IN 5.x USING
THE LATEST 5.x CODE, BEFORE UPGRADING FROM 5.x to 6.x.

ALWAYS BACKUP YOUR DATABASE BEFORE UPGRADING!

1) Before upgrading to 6.x, upload the latest 5.x versions of all
CCK modules, go to update.php and run all possible updates.

2) Disable all CCK modules and remove them from the modules folder
before upgrading.

3) Install Drupal version 6. Leave all contributed modules out of
the modules folder until core modules are up and running.
Set your administration theme to a core theme like Garland until
everything has been updated to help ensure you don't encounter
theme-related problems accessing the administration area.

4) Once core is running, upload and install the latest 6.x versions
of ONLY CCK CORE FILES (the ones in the tarball on the CCK
project page). Enable them, then go to update.php and run all
possible updates. DO NOT add any other CCK modules to the
modules folder until the core CCK files are updated and working
correctly.

5) After updating CCK core modules, you may get messages saying that
some updates failed and that you need to run update.php again.
If you get messages like that, keep re-running update.php until
you get no more messages.

6) Once the core CCK modules are updated and working correctly,
add other CCK modules to the modules folder, enable them,
and run update.php. For best results, do this one module at a
time so you can tell immediately if any of them create problems
without letting those problems interfere with other updates.

 
Rules

muss - je nach Version - ggf. noch einmal via update.php einzeln aufgerufen werden (dabei die drei Rules-Module wählen und jeweils aus der Auswahlliste das Update 6001 auswählen). In unserem Fall war das aber überflüssig, weil ein großer Teil der WorkflowNG-Regeln nicht mehr gebraucht wurden. Und die, die noch benötigt wurden, ließen sich nicht konvertieren, weil sie die State Machine benutzten.

Schritt 13: Neue Inhaltstypen, Module, Menüs und Taxonomy
Kommen neue Inhaltstypen hinzu oder ändern sich alte, so ist jetzt der richtige Zeitpunkt, um sie zu erstellen oder anzupassen. Das gleich gilt für Änderungen an der Menüstruktur, der Taxonomy oder beim Einsatz neuer Module.

In unserem Fall kam eine ganze Reihe neuer Module zum Einsatz:
  • Menu per Role
  • Menu Block
  • Advanced Book Blocks
  • Panels
  • Relevant Content
  • iTweak Login
  • Twitter
  • User Login Bar
  • Talk
Natürlich hatten wir die vorher schon in einer Testumgebung ausprobiert, so dass nur noch die Einstellungen entsprechend angepasst werden mussten.

Schritt 14: Diverse Konvertierungen

a) Views
Die Views von der alten Website müssen nach Views2 konvertiert werden, um weiter genutzt werden zu können. Wer neue Views in seiner Testumgebung erstellt hat kann diese einfach exportieren und in die neue Seite importieren.


Wenn alle Views funktionieren, sollte über "Ansichten >> Tools >> Convert >> Remove all Views 1 tables", die Datenbank aufgeräumt werden und die alten Views1-Versionen gelöscht werden.

b) Workflows müssen in Rules konvertiert werden. Neu erstellte Rules lassen sich ebenfalls via Ex- und Import aus einer Testumgebung übernehmen.
Das Update der alten WorkflowNG-Regeln geht so: Man ruft update.php auf und wählt im Schritt 2 ("Select Updates") "Select Versions". Dann wählt man bei den drei Rules-Modulen jeweils das Update 6001 im Dropdown-Menü und klickt auf "Update". Jetzt werden - soweit möglich - die Workflow-NG-Regeln konvertiert. "Soweit möglich" heißt in diesem Falle, dass keine Regeln konvertiert werden, die mit State Machines arbeiten, weil es die nicht mehr gibt. Begründung: die sind mit CCK machbar.

c) Einen Fehler brachte der in Drupal 6 neu hinzugekommene Filter HTML Corrector, der standardmäßig aktiv ist, mit sich. Am Anfang etlicher Nodes stand plötzlich der Text <!--paging_filter-->. Der Grund: das Paging-Modul war aktiv  und der HTML Corrector kollidierte mit dessen Filter. Die Lösung ist einfach: UnterVerwalten >> Einstellungen >> Eingabeformate bei jedem Eingabeformat, dass beide Filter verwendet, die Sortierung (Tab "Sortieren") so ändern, dass der Filter "Paging" nach dem Filter "HTML Corrector" steht.

d) Nun ist es an der Zeit die Blockpositionen in dem neuen Theme einzustellen. In unserem Falle waren es sogar mehrere Themes mit unterschiedlichen Blocksichtbarkeiten.

Schritt 15: Neuerstellung von Aliasen
Dieser Schritt ist nur erforderlich, wenn sich z.B. die Taxonomy verändert hat, oder die URL-Aliase aus anderen Gründen geändert werden sollen. Damit die Suchmaschinen, die ja zunächst noch die alten Pfade in ihrem Indes haben, nicht auf der Fehlerseite landen, werden die alten URLs via Redirect-Anweisung in der htaccess-Datei umgeschrieben. Das ganze ist eine kleine Fleißarbeit - je nach Änderungen in der Struktur kann man u.U. mit regulären Ausdrücken arbeiten. Ansonsten geht es nach "Schema F":

  1. Im Modul Pathauto die Ersetzungmuster wie gewünscht anpassen.
  2. Eine Tabelle erstellen, die alle alten Aliase und dem gegenüber die neuen enthält. Das sieht in etwa so aus:
    RewriteRule ^alter/pfad$ http://meine-domain.xy/der-neue/pfad [R=301,L]
  3. diese Tabelle wird dann in der htaccess eintragen, damit jede alte URL per 301-Redirect auf die neue gemappt wird.
  4. nun können die alten Aliase gelöscht werden.
  5. Anschließend werden alle Pfade neu generiert.
    Ach ja, hatte ich schon erwähnt, dass es Momente gibt, wo man mal wieder ein Backup der Datenbank machen sollte? Vor diesem Arbeitsschritt ist so ein Moment. ;-)
Schritt 16: Test der Seite. Funktioniert alles wie es soll, sind die Blöcke an den richtigen Positionen? Stimmt das Layout? Wenn alles zufriedenstellend aussieht und läuft kann die Seite jetzt wieder online geschaltet werden.
 
War doch gar nicht so schwer, oder?