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 ve