Contao 3.2.x

Ich bin ein bekennender Contao-Anhänger. aber manchmal wird meine Liebe auf eine harte Probe gestellt.

Wobei das — wie ich jetzt nach einigen schmerzhaften Experimenten weiß — typischerweise nicht dem Kernprogramm, sondern verwendeten Modulen geschuldet ist. Denn mit Version 3.2 gab es einige grundlegende Änderungen, die speziell die Nutzung von Bildern und anderen verlinkten Objekten betrifft. Die Idee, dass diese Elemente nicht mehr direkt, sondern logisch verwendet werden, ist toll. Denn dann werden im Fall der Fälle beispielsweise Namensänderungen durchgereicht, ohne dass ich mir Gedanken machen muss, wo jetzt womöglich Verknüpfungen ins Leere gehen.

Unglücklicherweise halten die Erweiterungen bei der raschen Entwicklung des Kerns nur bedingt Schritt. Oder die Entwickler haben einfach keine Zeit oder Lust mehr auf die Pflege. Nachvollziehbar, aber ärgerlich für Anwender. Insbesondere, wenn es dann ordentliche Löcher oder gleich die ganze Webseite in den Abgrund reißt, weil ein Modul partout nicht mehr mit der veränderten Arbeitsweise des Kerns zusammenarbeiten will.

Wer da wem und wie im Einzelfall die Zunge herausstreckt, habe ich nicht weiter ergründet. Allerdings hat sich für mich gezeigt, dass eine Fehlermeldung, oder eine vermeintlich unbrauchbar gewordene Webseite, die nur noch Fehlermeldungen wirft, keinen Grund zur Panik darstellt. In der Ruhe liegt die Kraft.

Da ich mittlerweile einige älteren Versionen < 3.2 hochgezogen habe, weiß ich mittlerweile, dass man sich mindestens an Version 3.1.5 mit easyUpdate3 heranschaffen muss. Bis dahin ist die Welt in Ordnung. Alle Module auf den dann verfügbaren Stand bringen und erst einmal Backups machen. Von den Webdateien und der dann sauberen Datenbank. EasyUpdate3 reduziert den Aufwand erheblich, wenn man mit einigen Besonderheiten klar kommt. Eine davon ist, dass grundsätzlich der Installationsprozess aufgerufen wird, damit dort die Datenbank aktualisiert wird. Auf dem Weg von Verisonen <3.2 nach oben habe ich die Erfahrung gesammelt, dass es sich lohnt, hier öfters einmal alles so zu lassen wie es ist, aber vorzubauen.

Ich setzte mittlerweile erst einmal den Datenbank-Treiber im Installationsschirm auf MySQLi. Denn der MySQL-Treiber wird ab 3.2.x (keine Ahnung, welche genau) nicht mehr unterstützt, was dann zu hässlichen Fehlermeldungen führt. Die „dauerhafte Verbindung“ setzte ich auf nein, weil ein ja hier ebenfalls Fehlermeldungen generiert. Mit dem Erreichen der Version 3.2 muss ein Datenbank-Update durchgeführt werden. Hierbei entscheide ich ein wenig nach Bauchgefühl, ob ich manche Tabellen und Elemente erst einmal überleben lasse, wie sie sind. Denn dort liegen teilweise die Infos, die dann ein Modul benötigt, wenn es auf die neue Version aktualisieren will. Blöd, wenn die dann weg sind. Dann wird es viel Handarbeit. Ich weiß das, weil ich das bereits hinter mir habe.

Manchmal wirft der Installer beim aktualisieren der Datenbank unspezifische Fehlermeldungen. Zumindest für jemanden, der nicht tiefer im Programm-Code steckt. Das ist ebenfalls kein Grund zur Nervosität. Mit der Zurück-Funktion des Browsers wieder in das Installer-Fenster gehen. Dort nicht mit alles auswählen den Rundumschlag versuchen, sondern Schritt für Schritt, vorzugweise von unten nach oben, die Datenbank aufräumen. Die Fehlermeldungen stammen häufig von abhängigen Feldern, was der Bereinigungsprozess speziell bei Erweiterungen teilweise nicht auflösen kann.

Das ist zwar sicherlich eine etwas unorthodoxe Herangehensweise, aber statt aufwändiger Analyse der Probleme und mit Unterstützung regelmäßiger Backups — auch in der Testumgebung — komme ich auf diesem Weg vergleichsweise schnell ans Ziel und habe eine aufgeräumte, aktuelle Version. Wenn ich etwas mehr Mut hatte, als es dem nächsten Schritt gut tut, wird das Backup aktiviert und vorsichtiger operiert. Sobald alles in der Testumgebung (bei mir ist das XAMPP) stabil läuft, geht es wieder in die freie Wildbahn.

Ein Hinweis noch zu XAMPP. Dort laufen einige Module nicht korrekt. Gefühlt sind das meistens welche, die auf Mootools und Co. zugreifen. Ich bin mittlerweile ziemlich rigide: Was nicht unter XAMPP läuft, fliegt raus. Dafür habe ich mir teilweise schon richtig Arbeit an den Hals geholt, im Gegenzug nutzen meine Seiten immer weniger Module, weil ich manches mit etwas mehr Aufwand von Hand erledige. Als Belohnung für die Mühe fahren diese Seiten bei Updates nicht an die Wand, was den Aktualisierungsaufwand verringert. Ob das in der Summe immer ein Bonus ist, weiß ich nicht, aber es spart nerviges Herumprobieren oder Herumärgern, weil eine Erweiterung (s.o.) noch nicht, oder generell nicht mehr für die aktuelle Version verfügbar ist. Denn so manche davon ist, wie ich mittlerweile ebenfalls weiß, mit mehr oder minder heißer Nadel gestrickt. Woraus sich dann im weiteren Verlauf die Probleme ergeben. Handgknüpfte Module in der Webseiten-Umgebung, gefüllt mit validem HTML, können überraschend viele Dinge ebensogut, machen es — für HTML-Kundige — übersichtlicher und reduzieren die Erweiterungsliste. Meine wichtigste Erkenntnis: Je weniger Erweiterungen, desto weniger Update-Stress.