18 Jun 2010

Drupal, erstes Core-Update

Submitted by ebertus

Über die in der Vergangenheit vereinzelt notwendigen Updates von Zusatzmodulen hinaus steht nun erstmals ein Core-Update von Drupal an. Die bisherige Version 6.16 soll durch 6.17 ersetzt werden; das Update ist kein Sicherheitsrelease, beinhaltet keine Neuerungen sondern im Wesentlichen Bug-Fixes, also Fehlerbereinigungen.

Die Bereitstellung der neuen, englischsprachigen Originalversion 6.17 war für sich genommen nur ein Hinweis, die erwartete, deutsche Anpassung folgte dann in wenigen Wochen. und steht nun auf der deutschen Drupal-Site zum Download bereit. Grund genug also und mehr als eine Fingerübung, dieses Update nun einmal praktisch umzusetzen.

Ehe man nun - gern mittels dieser Handlungsanweisung und zuerst auf einer lokalen (localhost) Kopie - praktisch heran geht, sind aus meiner Sicht noch einige Vorarbeiten zu leisten:

1. Prüfen und ggf. spätestens jetzt das Anpassen der Modulverzeichnisse vornehmen. Die Drupal-Coremodule liegen unter [...SiteRoot]\modules während die Zusatzmodule unter [...SiteRoot]\sites\all\modules ihren Platz auf dem Webserver haben. Gegebenenfalls sind also die Zusatzmodule zu deaktivieren, umzukopieren und wieder zu aktivieren. Bei meiner Installation hatte ich diese Struktur zwar nicht vom Start weg befolgt, dann aber nach einigen Wochen relativ schnell nachgeführt.

2. Prüfen und ggf. Deaktivieren (dann Löschen) von Modulen, die vielleicht mal eingebaut, im Grunde aber bislang nicht wirklich benötigt wurden. Wenn man später mal eine Zusatzfunktion benötigt, ist es wohl sinnvoller, dann den aktuellen Stand zu recherchieren, als "Fragmentleichen" weiter mitzuschleppen. Bei mir waren dies z.B. die mal getesteten, nie jedoch produktiv eingesetzten CCK- und JQ- Module.

3. Im Grunde klar, sollte die Backup-Strategie bei dieser Gelegenheit nochmals kritisch überprüft werden. Auch wenn (an ggf. mehreren Locations) lokale Kopien bereit gehalten und regelmäßig aktualisiert werden, so sollte dies nicht als Selbstlauf angesehen werden. Im konkreten Fall wird (teilautomatisiert) sowohl das Drupal-Verzeichnis als auch (nach dem Stopp der Dienste) das MySQL-Data Verzeichnis von Drupal mit einem Sync-Programm lokal auf dem Server, und sowohl im LAN, als auch über die WAN-Strecke (VPN-Tunnel) gesichert. Die jeweiligen Kopien, entweder via Localhost als auch als Reserveserver über eine weitergeleitete Domain sollten einwandfrei funktionieren.

4. Bezüglich der Daten empfiehlt sich (zumindest testweise) via PhpMyAdmin ein zusätzlicher SQL-Dump (Export), der dann auf einer lokalen Kopie (Import) wieder eingelesen wird. Vor einigen Wochen und mit rund 10 MB Dateigröße funktionierte dies auch noch einwandfrei. Nun ist die exportierte Datei jedoch mehr als 30 MB groß und das Importieren ergab eine (zum Glück aussagefähige) Fehlermeldung. Das vorab versuchte Update der PhpMyAdmin-Version von 2.11.9 auf 3.2.4 brachte keine Besserung. Gemäß der erhaltenen Fehlermeldung liegt das Problem in der php.ini, wo bereits vor einigen Wochen wegen dem vorher nicht funktionierenden Bildimports der Parameter "memory_limit" auf 128 MB angepasst wurde. Nun waren also noch "upload_max_filesize" und "post_max_size" d'ran, einfach ebenfalls mal auf 128 MB gesetzt. Lokal natürlich, da diese Dateien bzw. Verzeichnisse (Apache, PHP etc.) (natürlich) nicht automatisch synchronisiert werden. Nach dem Stopp der Dienste, dem Ändern der Parameter und einem Dienste-Neustart funktioniert der Import nun einwandfrei. Kritisch kann dieser (ggf. nicht mögliche) Zugriff bei reinem Webhosting sein, da die Provider sicher nicht so freizügig mit dem Speicher umgehen werden.

OK, ein weiterer Download von (bereinigtem) Programm und Daten des produktiven Servers auf eine lokale Installation und es kann los gehen. Die deutsche Version 6.17 ist bereits heruntergeladen, manuell entpackt und liegt in einem temporären Verzeichnis. Man loggt sich (in dieser Version ein letztes Mal) als Admin ein und setzt die Site in den Wartungsmodus. Dann werden die entsprechenden Dateien und Verzeichnisse (bis auf die genannten Ausnahmen) gelöscht und sofort die neuen Dateien/Verzeichnisse (der Version 6.17) kopiert. Nur für eine kurze Zeit (löschen/kopieren) ist also die Site vollkommen offline, vorher und nachher erhält der Besucher die entsprechende Wartungsmeldung.

Und wie kommt man als Admin nun wieder rein? Aus der Wartungsanzeige eher nicht, aber mit http://localhost/?q=user erscheint ein administratives Anmeldebild. Produktiv ist [localhost] auf einem Webserver natürlich durch den entsprechenden Domainnamen zu ersetzen. OK, dann weiter im Text, wie in der Updateanweisung beschrieben. Im vorliegenden Fall gab es keine Notwendigkeit, für ein Datenbank-Update. Der Statusbericht meldete den Drupal-Core mit 6.17 und war ansonsten sauber. Ein Cron-Lauf zum Abschluß, Einiges Bewegen auf der Site und es kann vom Wartungsmodus wieder auf "online" geschalten werden.

Lokal zumindest, das produktive System folgt demnächst - genauer: Samstag vormittag.