Mit dem im CMS webEdition integrierten Live-Update ist ein Update (eigentlich) eine sehr einfache und schnelle Angelegenheit. Über Hilfe > Update wird der Update-Prozess gestartet, indem auf dem Update-Server nach aktuellen Versionen gesucht wird. Für die verfügbaren Versionen gibt es zudem wichtige Update-Hinweise, wie z.B. benötigte Basistechnologien (PHP- und MySQL-Versionen). Erfolgt eine Update über mehrere Major-Releases (z.B. von webEdition 6.1 auf webEdition 6.3) werden auch hierfür spezielle Update-Hinweise gegeben. So kann es sinnvoll sein, erst auf webEdition 6.2 und dann auf webEdition 6.3 upzudaten.
Sofern sich das Update nur über wenige Releases erstreckt, tauchen (wenn überhaupt) nur wenige Probleme auf. Dabei arbeite ich immer mit Entwicklungs- und Livesystemen, um die neue Version und den Update-Prozess zu testen. Ganz anders sieht es aus, wenn eine webEdition Installation von z.B. Version 3.5 oder 4.1 auf die aktuelle Version gebracht werden soll.
So kommt man von webEdition 4 nach webEdition 6.3
Aktuell muss ich ein webEdition 4.1.2.6 auf webEdition 6.3.3 updaten. Im Vorfeld wollte der Kunde natürlich ein Angebot erhalten. Da es sich hierbei um ein Projekt, dass ich vor 5 Jahren selbst entwickelt habe, konnte ich auch den Template-Code gut einschätzen. Dennoch ist das Update alles andere als schnell gemacht und nicht ganz einfach abzuschätzen. Hierbei darf nicht vergessen werden, dass zwischen den beiden Versionen 5 Jahre Entwicklungszeit liegen. Zudem haben sich auch die Basistechnologien (PHP und MySQL) geändert. Zudem ist ein Update über das integrierte Live-Update nicht möglich.
Bei einem Update, der sich über so viele Releases erstreckt, ist es zudem sinnvoll den Template-Code zu optimieren und an die Möglichkeiten der aktuellen webEdition Version anzupassen, um auch bei zukünftigen Versionen updatefähig zu sein.
1. Datensicherung von webEdition 4.1.2.6
Wichtig ist zunächst ein Backup der aktuellen webEdition Installation zu erstellen. Dazu gehört ein Datenbankdump und die komplette Sicherung des “site” Verzeichnisses im Verzeichnis “webEdition”. Neben dem Komplettdatenbankdump habe ich ein weiteren Dump mit der Option “Drop Table” und ohne die Tabelle “tblUser” erstellt. In dieser Tabelle sind alle Backend-User enthalten.
2. Manuelle Installation von webEdition 5.1.2.5
Über den Online-Installer ist derzeit nur die Installation von webEdition 6 oder höher möglich, daher muss auf die manuelle Installation des letzten webEdition 5 zurückgegriffen werden, um von hier aus dann schrittweise über das Live-Update zur Version 6.3.3 zu gelangen. Nach der Installation wird dann der zuvor gesicherte “site” Ordner via FTP in das frisch installierte webEdition übertragen. Dann wird der DB-Dump (ohne “tblUser”) direkt in die DB eingespielt. Ich habe die “tblUser” weggelassen, da ich mich mit dem via DB-Dump eingespielten User nicht einloggen konnte … warum auch immer. Anschließend ein Rebuild durchführen und schauen was passiert …
Bei mir trat das Problem auf, dass alle webEdition Dokumente, die auf Vorlagen basieren, zwar korrekt rebuilded und im Frontend angezeigt wurden, jedoch im Backend die Fehlermeldung Das Dokument bzw. Verzeichnis existiert nicht! ausgaben. Dieser Fehler lässt sich mit einer manuellen Bereinigung der tblTemporaryDoc beseitigen. Nach einem Rebuild ließen sich dann auch Dokumente bearbeiten. Seltsamer Weise funktionierte keine der <we:listview>’s … es gab einfach keine Ausgabe. Dennoch erstmal ein Backup machen.
3. Update auf webEdition 6.0.0.6
Das Update auf webEdition 6 ist jetzt wieder über das Live-Update möglich. Auch wenn bereits jetzt ein Update auf 6.3.3 möglich wäre, sollten die folgenden Versionen schrittweise installiert werden. Nach dem Update sollte auf jeden Fall das Updatelog überprüft werden, um Probleme zu erkennen. Nach einem Rebuild war an dieser Stelle das Problem mit den <we:listview>’s beseitigt *freu*
4. Update auf webEdition 6.1.0.2
Nach dem Update auf webEdition 6.1.0.2 prüfen wir wieder das Updatelog. In meinem Fall gab es Probleme mit der tblPrefs, bei der mehrfach identische Einträge angelegt wurden, die manuell zu bereinigen sind. Anschließend wieder einen Rebuild durchführen und testen, ob die Website weiterhin funktioniert. Jetzt wäre auch die passende Gelegenheit ein Backup zu erstellen 
5. Update auf webEdition 6.2.0
Wir führen wieder ein Update durch und prüfen anschließend das Updatelog. Ab Version 6.2 ist auch ein Errorlog über Hilfe > Fehlerlog integriert, dass zunächst über die Einstellungen aktiviert werden sollte. Anschließend wieder ein Rebuild durchführen und das Errorlog aufrufen. Hier können erste Fehler in der Template-Programmierung erkannt werden.
6. Update auf webEdition 6.3.3
Im vorletzten Schritt führen wir ein Update auf die Zielversion durch. Anschließend wieder das Updatelog prüfen, einen Rebuild durchführen und das Errorlog einsehen. Durch die umfangreichen Änderungen am Tag-Parser werden hier Syntax-Fehler bei webEdition-Tags sichtbar, die nun korrigiert werden können. Das kann je nach Projektumfang und Qualität der Programmierung unterschiedlich lange dauern …
7. Template-Optimierungen durchführen
Nachdem ein aktuelles Entwicklungssystem zur Verfügung steht, sollte der Template-Code optimiert werden. Bei webEdition 4 Projekten musste ich immer noch sehr viel PHP-Code nutzen, weil z.B. Tags wie z.B. <we:ifIsDomain> etc. nicht existierten.
Abhängig vom Projektumfang können die notwendigen Syntaxbereinigungen im Schritt 6 und die anfallenden Code-Optimierungen im Schritt 7 unterschiedlich aufwendig sein. Wie sich bereits an den einzelnen Update-Schritten sehen kann, ist bereits das “reine” Systemupdate durch mögliche “händische” Datenbankbereinigungen nicht einfach und schnell möglich. Dadurch wird das gesamte Update-Prozedere zeitintensiv!
Sofern alle Entwicklungsarbeiten abgeschlossen sind, muss dann auf dem Livesystem noch webEdition 6.3.3 installiert werden. Zum Schluss wird dann ein webEdition Backup des Entwicklungssystem erstellt und ins neu installierte Livesystem eingespielt … fertig!