Diese Beschreibung versteht sich als Kurzanleitung für erfahrene Drupal-Administratoren, die eine Checkliste für Aktualisierungen des Systems haben wollen. Es wird also vorausgesetzt, dass der grundsätzliche Aktualisierungsmechanismus einschließlich der Verzeichnisstruktur auf dem Server bekannt ist. Desweiteren wird als selbstverständlich vorausgesetzt, dass die administrativen Aktionen auf der Website mit entsprechenden Berechtigungen ausgeführt werden. Schließlich sei betont, dass es hier ausschließlich um die Aktualisierung einer Drupal-Version 6.x1 auf 6.x2 oder eines Zusatzmoduls für 6.x geht (sog. minor update); Aktualisierungen der Hauptversion (etwa von 5.x1 auf 6.x2 oder 6.x1 auf 7.x2) sowie von Zusatzmodulen zwischen verschiedenen Hauptversionen werden hier nicht betrachtet.
Eine ausführliche Anleitung zur Aktualisierung insbesondere des Grundsystems (innerhalb der 6.x-Reihe) findet man im Administration Guide von drupal.org in diesem Howto. Anfänger sollten zuerst dort nachsehen.
Die Schritte zum Aktualisieren von Zusatzmodulen beinhalten im Wesentlichen eine Teilmenge der entsprechenden Schritte zur Aktualisierung des Grundsystems. Daher wird hier beides zusammen dargestellt, wobei Schritte, die nur das Grundsystem betreffen, farblich sowie durch die Markierung [core] textlich hervorgehoben sind.
Die Aktualisierung eines Systems ist immer gefährlich und kann zur Folge haben, dass es anschließend nicht mehr funktioniert oder gar weitergehende Zerstörungen anrichtet. Die folgenden Schritte sind daher auf eigene Gefahr und ohne Gewährleistung anzuwenden!
-
Lade die zu aktualisierenden Dateien herunter und packe sie ggf. aus. [core] Lösche aus der lokalen Kopie die Dateien .htaccess, robots.txt und das Verzeichnis sites, falls nicht angesagt ist, dass diese aktualisiert wurden. Falls doch, müssen ggf. manuelle Änderungen vorgenommen werden; dann sollte man die betroffenen Dateien unbedingt in die Sicherungskopie der Dateien vom Server (s. u.) einschließen.
- Schalte die Website in den Wartungsmodus.
- [core] Erstelle eine Sicherungskopie der Dateien vom Server. Benutze dazu ein geeignetes FTP-Programm, z. B. FileZilla oder Konquerer. Ob man nun alle Server-Dateien sichert, oder nur die aus sites/default (letzteres enthält u. a. die Einstellungen für die Website und hochgeladene Dateien), ist dem Anwender überlassen. Es ist kein Fehler, diesen Punkt auch bei Zusatzmodulaktualisierugen anzuwenden, obwohl bei sorgfältiger Vorgehensweise nicht unbedingt notwendig.
- Mache eine Sicherungskopie der Datenbank. Dies ist unerlässlich, da bei jedem Update nicht vorhersehbare Dinge passieren können. Man kann dazu z. B. das backup_migrate-Modul verwenden oder auch etwa phpMyAdmin. Es ist keine schlechte Idee, gelegentlich die eine oder die andere Methode zu verwenden, um im Fall der Fälle verschiedene Wiederherstellmöglichkeiten zu haben.
-
[core] Deaktiviere alle Zusatzmodule. Notiere zuvor den aktuellen Status etwa als Bildschirmfoto vermöge Firefox Shooter oder manuell. Dies wird bei der Reaktivierung gebraucht!
-
Falls Zusatzmodule aktualisiert werden, lösche die betroffenen alten Dateien vom Server. Dies ist zu empfehlen, da sonst alte, nicht überschriebene Dateien Inkonsistenzen hervorrufen können. [core] Für eine Aktualisierung des Grundsystems allein ist das i. Allg. nicht erforderlich, solange man sich innerhalb einer Hauptversion (hier: 6.x) bewegt.
- Kopiere die neuen Dateien auf den Server in das jeweils zugeordnete Verzeichnis (i. Allg. unter sites/all/modules oder [core] das Stammverzeichnis).
- Führe update.php aus.
-
[core] Reaktiviere alle zuvor abgeschalteten Zusatzmodule und führe update.php erneut aus.
- Schalte den Wartungsmodus ab.
- Prüfe die aktualisierte Website.
Deaktivierung der Zusatzmodule unnötig?
In Schritt 5 ([core] Deaktiviere alle Zusatzmodule...) wird angeraten, während der Aktualisierung des Grundsystems alle aktiven Zusatzmodule abzuschalten; in Schritt 9 ([core] Reaktiviere alle zuvor abgeschalteten Zusatzmodule...) findet dann die Umkehroperation statt.
Diese Vorgehensweise entspricht der Dokumentation in der Datei UPGRADE.txt des Drupal-Grundsystems (in der Version 6.25 etwa sind das die dortigen Punkte 5 und 12).
Diese beiden Schritte gehören zu den aufwendigsten bei einer Aktualisierung des Grundsystems, da die Zusatzmodule teilweise voneinander abhängen und nicht beliebig ein- und ausgeschaltet werden können; außerdem muss man bei der Reaktivierung sehr sorgfältig vorgehen, um wirklich den ursprünglichen Zustand wiederherzustellen, da sonst das Gesamtsystem möglicherweise nicht mehr so funktioniert wie gedacht. Es handelt sich also um eine potentielle, nicht zu unterschätzende Fehlerquelle.
Nun gibt es Hinweise darauf (etwa hier), dass dieses Abschalten von Zusatzmodulen bei einem sog. minor update (also etwa von 6.x1 auf 6.x2 – und nur davon ist in diesem Beitrag die Rede) gar nicht nötig ist. Ich habe das inzwischen bei zwei Systemen und jeweils zwei Grundaktualisierungen (je von 6.22 auf 6.23 sowie von 6.23 auf 6.25) ausprobiert, habe also die Schritte 5 und 9 ausgelassen, ohne dass irgendein Problem aufgetreten ist. Natürlich kann ich keine Allgemeingültigkeit garantieren (jedes System ist anders), aber einen Versuch – mit den beschrieben Sicherheitsmaßnahmen und auf eigene Gefahr – wäre es vielleicht wert.
Disabling of Custom Modules Unnecessary?
According to step 5 ([core] Disable all custom modules...), during the update of the core system all active custom modules should be switched off; in step 9 ([core] Re-enable all previously disabled custom modules...) the reverse operation takes place.
This procedure corresponds to the documentation in the file UPGRADE.txt of the Drupal core system (for version 6.25, e.g., these are the items 5 und 12 there).
These two steps belong to the most expensive tasks during an update of the core system, since the custom modules partially depend on each other and can't be switched on and off arbitrarily; furthermore, one has to be very careful when re-enabling the modules to re-establish the initial status, because otherwise the whole system might not behave as thought anymore. Hence, this is a potential, not to underestimate source of failure.
Now, there are hints (say here), that this disabling of custom modules during a minor update (i.e., from 6.x1 to 6.x2, say – and only such is in question in this contribution) is unnecessary. I tryed it out meanwhile for two systems and two core updates, respectively (each from 6.22 to 6.23 as well as from 6.23 to 6.25), i.e., leaving out steps 5 and 9, without any problem appearing. Of course, there is no guarantee for general validity (every system is different), but it may be worth a try – obeying the safety measures described above and on your own risk.