Upgrade von 2.6.7 auf 2.7

Obwohl ich schon vor einiger Zeit über das Erscheinen von Website Baker 2.7 berichtet hatte, lief meine Site noch etliche Wochen auf Website Baker 2.6.7. Grund hierfür war vor Allem die Furcht vor dem Verlust von Daten – seien es nun Texte oder Einstellungen.

Nachdem ich die anstehende Aufgabe nun einige Zeit vor mir her geschoben habe, musste es dann aber irgendwann doch sein. Schliesslich bietet Website Baker 2.7 gegenüber dessen Vorgänger einige neue Funktionen und schliesst offene Sicherheitslücken.
An dieser Stelle möchte ich anderen Upgrade-Willigen den Weg zur derzeit aktuellsten WB-Version (Stand 5.10.2008) aufzeigen und – soweit das geht – vielleicht etwas die Bedenken vor dem Schritt in die richtige Richtung nehmen.

Soviel schon einmal vorab: Es war leichter als befürchtet, jedoch schwerer als erhofft.

WebsiteBaker-Upgrade

Nicht ganz Schmerzfrei: Das Upgrade von WebsiteBaker 2.6.7 auf 2.7

Obwohl ich schon vor einiger Zeit über das Erscheinen von Website Baker 2.7 berichtet hatte, lief meine Site noch etliche Wochen auf Website Baker 2.6.7. Grund hierfür war vor Allem die Furcht vor dem Verlust von Daten – seien es nun Texte oder Einstellungen.

Nachdem ich die anstehende Aufgabe nun einige Zeit vor mir her geschoben habe, musste es dann aber irgendwann doch sein. Schliesslich bietet Website Baker 2.7 gegenüber dessen Vorgänger einige neue Funktionen und schliesst offene Sicherheitslücken.
An dieser Stelle möchte ich anderen Upgrade-Willigen den Weg zur derzeit aktuellsten WB-Version (Stand 5.10.2008) aufzeigen und – soweit das geht – vielleicht etwas die Bedenken vor dem Schritt in die richtige Richtung nehmen.

Soviel schon einmal vorab: Es war leichter als befürchtet, jedoch schwerer als erhofft.

Grundlage für das Upgrade sollte aber auf jedem Fall die offizielle Beschreibung auf der Website-Baker-Projektsite sein – dieser Text ist lediglich als Erfahrungsbericht und Hilfestellung zu verstehen.

Datensicherung

Die offizielle Upgrade-Anleitung auf der Website-Baker-Projektsite empfiehlt als erstes die Durchführung eines Backups. Logisch – das sollte die Grundlage jedes größeren Eingriffes an Dateien sein. Eigentlich hatte ich mir über diesen Schritt keine großen Gedanken gemacht aber hier sollten die Probleme bereits beginnen.

Die MySQL-Datenbank habe ich sowohl via WB-Backend als auch via phpMyAdmin vorgenommen. Doppelt hält ja bekanntlich besser; und falls die Backup-Funktion von WB einen Fehler hat, habe ich auf jeden Fall noch das Backup von phpMyAdmin (das Tool hat sich mittlerweile zum Quasi-Standard für die MySQL-Administration gemausert und muss daher doch einfach gut sein…)

Anschliessen hatte ich vor, ALLE Dateien auf dem Server via FTP zu spiegeln. Nicht wie auf websitebaker.org vorgeschlagen nur die Verzeichnisse /pages und /templates. Was hat man hat das hat man.
Unter Mac OS X habe ich bisher immer gerne Cyberduck für den Datentransfer via FTP genutzt. Nicht zuletzt, weil Cyberduck kostenlos ist. Allerdings hat das diesmal überhaupt nicht funktioniert: Das Kopieren brach ständig bei etwa 80% ab (Verbindung fehlgeschlagen) und dann musste ich komplett von vorne beginnen. Nachdem ich es dann nach knapp einer Stunde immer noch nicht geschafft hatte, meine zirka 20 MB große WB-Installation zu sichern, sah ich die letzte Rettung im Versuch, ein anderes Programm mit der Spiegelung zu beauftragen.
Da ich schon oft davon gehört hatte, versuchte ich Transmit – einen kostenpflichigen FTP-Client von dem es jedoch eine 15-Tage-Testversion gibt. Und siehe da: Das Kopieren aller Dateien klappte auf Anhieb. Ich habe keine Ahnung, was die Ursache für das erstmalige Versagen von Cyberduck war, auf jeden Fall hat in meinem Fall der Umstieg auf eine andere Software das Problem behoben.

Vorarbeiten, Schritt 1: Die Sprachdatei(en)

Als nächsten Schritt sieht die offizielle Upgrade-Anleitung das Ersetzen der Sprachdateien vor. Hierfür ist zunächst zu prüfen, ob die Dateien via FTP überschrieben werden können. Um das heraus zu finden, könnte man zum einem es einfach auf einen Versuch ankommen lassen oder man schaut via FTP-Client auf den Server und überprüft den Datei-Eigentümer. Ist als Eigentümer der gleiche Name eingetragen, wie der Name des FTP-Users (siehe Logindaten) so lässt sich die betroffene Datei auch von diesem Nutzer (per FTP) ändern. Anderfalls nicht. Dateien die über das WB-Backend installiert wurden (per PHP) erhalten automatisch den Eigentümer, mit dem das verarbeitende Skript auf die Datei zugreift. Häufig ist das der Nutzer „wwwrun“ – „www“ oder „public“ habe ich aber auch schon gesehen. In diesem Fall kann die Datei nicht mehr über den FTP-Client überschrieben, geändert, gelöscht oder verschoben werden.

FTP Dateiberechtigungen

Dateiberechtigungen sorgen hin und wieder für Probleme – so auch in diesem Fall.

In meinem Fall wurde die Sprachdatei über das WB-Backend installiert und zeigte daher den Eigentümer „wwwrun„. Daher habe ich mich am Backend angemeldet und die neue Sprachdatei „DE.php“ aus dem zuvor herunter geladenen Website-Baker-Installationspaket installiert. Anschliessend habe ich das komplette Verzeichnis „language“ aus dem WB-Paket gelöscht.

Vorarbeiten, Schritt 2: Der FCKEditor

Wie in der offiziellen Anleitung zu lesen ist, beinhaltet WB 2.7 bereits den FCKEditor – mein unter WB 2.6.7 manuell installierter FCK musste daher zunächst einmal entfernt werden. Das ging problemlos über die Deinstallions-Routine unter „Erweiterungen“ –> „Module“ im WB-Backend. Nach der Deinstallation war unter „Optionen“ –> „WYSIWG-Editor“ der Eintrag „kein“ ausgewählt – das habe ich auch so gelassen (an dieser Stelle zurück auf „HTMLArea“ umzustellen fand ich unnötig).

Vorarbeiten, Schritt 3: Das show_menu2 Snippet

Um meine Navigation besser gestalten zu können, hatte ich unter WB 2.6.7 „show_menu2“ installiert. Auch das ist nun bereits in WB 2.7 von Haus aus mit an Bord und muss daher zunächst aus der bestehenden Installation entfernt werden. Auch dies ging problemlos über das WB-Backend.

Vorarbeiten, Schritt 4: Verwaltungsprogramme

Als vorletzter Schritt in der Vorbereitung muss geprüft werden, ob bestimmte Verwaltungsprogramme unter WB 2.6.7 installiert sind – falls dem so ist, müssen diese entfernt werden. Die offizielle Anleitung verweist auf diese Liste. In meinem Fall traf dies nicht zu.

Vorarbeiten, Schritt 5: Form und News Modul

Da mit WB 2.7 neue Versionen des Form- und des News-Modules eingeführt werden, werden bestehende Einstellungen bei der Installation überschrieben. Da ich zumindest die Ausgabe des Form-Moduls meinen Wünschen angepasst hatte, musste ich nun zunächst alle Einträge aus den Einstellungen in eine Textdatei auf meinen Rechner kopieren um sie später wieder einzutragen.
Beim zurück Kopieren nach der Installation von WB 2.7 ist jedoch das ein oder andere zu beachten – mehr dazu später.

Eingabefelder WebsiteBaker News-Modul

Die Eingabefelder für die anpassbare Ausgabe in den Einstellungen des News-Modules. (Hier schon auf WB 2.7)

Die Eingabefelder für die anpassbare Ausgabe in den Einstellungen des News-Modules.
(Hier schon auf WB 2.7)

Das Upgrade

Nachdem alle in der offiziellen Upgrade-Anweisung vorgesehenen Vorbereitungen getroffen sind, geht es nun an das eigentlich Upgrade auf Website Baker 2.7. Das Installationsverzeichnis hatte ich ja bereits entpackt um die Sprachdatei zu extrahieren – nun muss das Ganze auf den Server.

Ein Beispiel:
Nehmen wir mal an, auf dem Server (WB 2.6.7) existiert ein Verzeichnis namens „vz1“ und darin befinden sich die dateien „datei1“ und „datei2„. Im Installtionsverzeichnis (WB 2.7) gibt es auch einen Ordner „vz1“ welcher jedoch nur eine Datei namens „datei1“ enthält. Beim Überschreiben des vorhanden „vz1“ auf dem Server mit dem neuen „vz1“ aus dem Installationspaket wird versucht werden die vorhandene Datei „datei2“ zu löschen, da diese im neuen „vz1“ nicht vorkommt. Während „datei1“ problemlos via FTP schreibbar wäre, ist es „datei2“ nicht – und so scheitert der ganze Kopierprozess an „datei2“ welche eigentlich gar keine Rolle spielt.

Daher empfehle ich, die neuen WB 2.7-Dateien Verzeichnis für Verzeichnis zu kopieren.
Also jedes Verzeichnis einzeln öffnen (immer parallel lokal und auf dem Server) und dann die Inhalte von der lokalen Platte auf den Server zu kopieren.

Aber Achtung: Die Datei „config.php“ und das Verzeichnis „/install“ dürfen nicht mit übertragen werden! („config.php“ enthält alle Einstellungen und „/install“ wird nur bei einer kompletten Neuinstallation benötigt).

Anschliessend muss der komplette Browser-Cache und die Cookies gelöscht werden. Ist dies geschehen, kann über http://domainname.de/wb-verzeichnis/upgrade-script.php die Upgrade-Prozedur gestartet werden. Jede Operation des Skriptes wird im Idealfall mit einem grünen „OK“ quittiert.

WB 2.7 ist nun installiert.
Soweit so gut.

Nacharbeiten, Upgrade-Skript löschen

Als erstes sollte nun das Upgrade-Skript vom Server gelöscht werden. Das geschieht wieder über den FTP-Client.

Nacharbeiten, Template anpassen

Das es unter WB 2.6.7 zu invalidem XHTML geführt hat, hatte ich folgenden Code im Head des Templates auskommentiert:

<?php
if(function_exists('register_frontend_modfiles')) {
  register_frontend_modfiles('css');
  register_frontend_modfiles('js');
}
?>

Nun muss das aber unbedingt wieder rein, da einige Module (auch das Form-Modul) ansonsten nicht korrekt funktionieren. Daher – falls nicht schon geschehen – die oben gezeigten Zeilen irgendwo zwischen und notieren – am Besten unterhalb der Einbindung der eigenen CSS- und JS-Dateien.
Dieser Code-Schnipsel sorgt dafür, dass Module ihr eigenes CSS und JS im Head der Seite registrieren können. Das CSS der Module lässt sich natürlich später im WB-Backend in den Modul-Einstellungen anpassen.

Ein erster Blick auf Website Baker 2.7

Nun war endlich der Zeitpunkt gekommen an dem ich überprüfen konnte, ob meine Arbeit Früchte getragen hat. Als rief ich meine Website (das Frontend) über http://www.andreherdling.de auf und war erschrocken, was ich da sah:

Auf meiner Startseite vom Typ „News“ herrschte gestalterisches Chaos. Der Footer war irgendwo in den Content-Bereich verrückt und der Rest hing dementsprechend auch nicht an den Stellen an den ich es gerne gehabt hätte. Ich atmete aber auf, als ich feststellte, das diese Problem ausschliesslich auf die News-Seiten begrenzt war.
Die Lösung war jedoch sehr einfach: Ich hatte meine angepasste Ausgabe des News-Modul noch nicht  zurück in dessen Einstellungen kopiert – aber ich hatte sie ja zuvor gesichert!
Also öffnete ich die Textdatei auf meinem Rechner und kopierte alles Block für Block zurück in das WB-Backend. Danach sah meine Seite aus wie gewohnt.

Lediglich die Ausgabe von Zeit und Datum in den News-Beiträgen funktionierte nicht – stattdessen tauchte dort nur „[TIME]“ und „[DATE]“ auf. Das legte die Vermutung nahe, dass die Syntax für die Platzhalter gegenüber WB 2.6.7 geändert wurden ist. legte ich eine neue Seite vom Typ News an und verglich die Einträge.

Und siehe da:

aus [TIME] war [MODI_TIME] geworden (Änderungszeit)
aus [DATE] war [MODE_DATE] geworden (Änderungsdatum)
und neu ist [PUBL_DATE] - das Veröffentlichungsdatum

Die neue Trennung in Veröffentlichungsdatum und Änderungsdatum ermöglicht es nun auch, das Datum der letzten Änderung explizit im Artikel angegeben:

Letze Aktualisierung am [MODI_DATE] um [MODI_TIME]
Schade nur, dass auf diese Änderung nicht in der offiziellen Upgrade-Anleitung hingewiesen wird.

Und noch etwas ist mir etwas negativ aufgefallen:
Als ich Seiten vom Typ News mit eingeschalteter Kommentarfunktion durch den HTML-Validator des W3C geschoben habe, entdeckte dieser mehrere „&“ ohne entsprechende Entität im XHTML-Quelltext. Der Code war also invalid.
Unter WB 2.6.7 hatte ich dies Problem bereits speziell beim automatischen Anhängen der PHP-Session-ID. Dort habe ich das durch folgende Regel in der .htaccess gelöst:

php_value arg_separator.output &

Nun war diese Regel aber wirkungslos, da dieses „&“ nicht beim Anhängen der PHP-Session-ID auftrat sonder bei der Übergabe von Werten an die Kommentar-Funktion:

.../news/comment.php?id=24&sid=10

Ich habe das dann gelöst indem ich die „view.php“ des News-Modul in den Zeilen 312 und 343 geändert habe:

aus
.../news/comment.php?id=24&sid=10
wurde
.../news/comment.php?id=24&sid=10

 

Mein Fazit

Ich hatte es ja bereits zu Anfang geschrieben: Es war leichter als befürchtet, jedoch schwerer als erhofft.
Gerade wenn man an seiner vorhandenen WB-Installation Veränderungen vorgenommen und neue Module installiert hat, kann das Upgrade schon einige Kopfschmerzen bereiten. Für jemand der sich halbwegs mit (X)HTML, PHP und den Eigenheiten eines Webserver auskennt sollte das auf alle Fälle machbar sein.

Für Einsteiger dürfte es da schon deutlich schwieriger sein – aber vielleicht greifen Einsteiger auch deutlich weniger in die Standardinstallation ein.

Auf jeden Fall sollte man für das Upgrade großzügig Zeit einplanen und sich selbst auch Zeit lassen. Dank dem sehr aktiven Website-Baker-Forum und der Google-Suche sollten sich eigentlich alle auftretenden Problem lösen lassen.

Ich bin dennoch sehr froh und erleichtert es endlich hinter mir zu haben und nun von den neuen Funktion profitieren zu können.

Weiterführende Informationen


 

Schreibe einen Kommentar