Contao Updates: Das solltest du wissen

In diesem Beitrag dreht sich alles um Contao Updates: Wie wird zwischen den Contao Updates unterschieden? Wann ist ein Update sinnvoll? Und welche Möglichkeiten gibt es diese durchzuführen?

In den letzten Jahren haben wir nicht wenig Zeit damit verbracht, Contao-Installationen für unsere Kunden zu aktualisieren. Und auch wenn wir das jetzt schon eine Weile machen – ein wenig Anspannung bleibt dann auch nach so vielen Jahren immer noch. Gerade wenn man einen etwas größeren Versionssprung macht und mehr als 2 bis 3 Contao-Erweiterungen einsetzt. Denn … kein Contao Update und kein Projekt ist wie das andere.

Wenn du bisher nur wenige Contao Updates durchgeführt hast, solltest du dich zunächst mit den Begrifflichkeiten und der Unterscheidung zwischen regelmäßigen und unregelmäßigen Aktualisierungen vertraut machen.

Regelmäßige Contao Updates (Major- und Minor-Release)

2011 hat Contao eine transparente Update-Strategie eingeführt. Dadurch weißt du genau, wann du dich mit den regelmäßigen und erwartbaren Contao-Updates, den Major- und Minor-Releases auseinandersetzen solltest.

1. Major-Release

Ein Major-Release ist ein Update von z. B. Contao 3 auf Contao 4. Wie im Release-Plan zu sehen, werden Major-Releases bei Contao nur in Abständen von mehreren Jahren veröffentlicht. Sie beinhalten neue Funktionen, aber auch Änderungen an der API, Datenstruktur und den Templates. Im aktuellen Fall, dem Wechsel von Contao 3 auf 4, ist dies zum Beispiel die Umstellung auf das PHP-Framework Symfony als Basis. Dieses Update ist mit großem Aufwand verbunden, angepasste Templates müssen überarbeitet werden und inkompatible Erweiterungen aktualisiert oder ersetzt werden.

2. Minor-Release

Ein Minor-Release ist ein Update von z.B. Contao 4.7. auf 4.8. Minor-Releases werden alle 6 Monate, immer im Februar und im August, veröffentlicht. Auch Minor-Releases bringen neue Funktionen mit, im Unterschied zu Major-Releases bleiben allerdings große Teile kompatibel. Eine Umstellung ist auf die neue Version ist daher in der Regel mit kleineren Anpassungen möglich.

3. Bugfix-Release

Ein Bugfix-Release ist ein Update von z.B. Contao 4.8.4 auf 4.8.5. Dieses Update enthält entweder Fehlerbehebungen, um Funktionen wiederherzustellen, die durch ein früheres Update gestört wurden oder schließt bekanntgewordene Sicherheitslücken in Contao. Es enthält keine neuen Funktionen und es wird versucht, die API, Datenstruktur und Templates nicht anpassen zu müssen, damit diese Updates möglichst einfach und schnell installiert werden können.

Mittlerweile werden Bugfix-Releases ebenfalls soweit möglich geplant und vorab angekündigt. Das verschafft Agenturen die Möglichkeit, ihre Kunden auf das anstehende Update vorzubereiten.

Gerade bei Sicherheitslücken ist ein schnelles Handeln erforderlich, damit Dritte diese Sicherheitslücke nicht ausnutzen können, um Teile der Website zu verändern oder zu manipulieren. Deswegen solltest du stets das aktuelle Minor-Release oder die aktuelle LTS-Version einzusetzen, um im Fall der Fälle schnell handeln zu können.

Das Problem bei Sicherheitslücken ist allerdings auch, dass sie selten alleine kommen. So folgten gerade bei großen Sicherheitslücken in Contao u.U. noch 1-2 weitere Bugfix-Releases, mit denen weitere, in diesem Zusammenhang entdeckte Sicherheitslücken geschlossen wurden. Du kannst dir also überlegen: Update direkt nach Entdeckung ausführen oder noch ein paar Tage warten, das Risiko eingehen, dass die Seite „gehackt“ werden könnte, aber dafür dann auch die Folge-Bugfix-Releases mitnehmen?

Long-Term-Support für ältere Contao-Versionen

Major-Release Veröffentlichungen werden von vielen Contao-Nutzern kritisch betrachtet, da die Änderungen teilweise gravierend für die Wartung und Entwiklung sind.

Beispiel: Bei der Einführung von Contao 4 wurden die Anforderungen an den Server spürbar angehoben werden. Die Folge: Contao ließ sich nicht mehr auf jedem x-beliebigen Hoster betreiben. Aus diesem Grund haben sich damals viele Contao-Nutzer für die Verlängerung des Long-Term-Supports, also der Versorgung einer älteren Contao Version mit Bugfixes und Sicherheitsupdates, ausgesprochen.

Und auch wir bei Erdmann & Freunde waren damals eher geteilter Meinung: Einerseits ist die Umstellung auf Symfony in Contao 4 ein richtiger und wichtiger Schritt, damit Contao auch in Zukunft wettbewerbsfähig bleibt. Andererseits bringt Contao 4 für viele Kundenprojekte große Unsicherheiten mit:

• Erfüllt der Hoster des Kunden alle Voraussetzungen?
• Werden alle eingesetzten Contao-Erweiterungen auch unter Contao 4 funktionieren?
• Werden wir Fehler, die während des Updates auftreten können, kurzfristig beheben können? (weniger Contao 4 Nutzer = weniger Probleme & weniger Support im Contao-Forum)

Deswegen laufen bei uns aktuell (Stand März 2016) noch alle Kunden-Projekte auf der LTS-Version Contao 3.5. Mittlerweile läuft der Großteil unserer Kundenprojekte auf Contao 4.4 oder neuer und wir unterstützen auch andere Agenturen, ihre Projekte auf Contao 4 zu aktualisieren.

Wann ist ein Contao Update sinnvoll?

Ob und wann ein Contao Update sinnvoll ist, lässt sich pauschal nicht sagen:

• Welche Contao Version wird verwendet? Verwendest du das aktuelle Minor-Release bzw. die aktuelle LTS-Version?
• Welche Contao-Funktionen (z.B. News, Events, Formulargenerator) werden genutzt? Ist die Funktionsweise beeinträchtigt? Gibt es neue Funktionen, die du benötigst?

Ein Bugfix-Release, dass eine Funktion repariert, die du gar nicht verwendest, kannst du in der Regel problemlos überspringen. Und auch bei der ein oder anderen potentiellen Sicherheitslücke kannst du schauen, ob du wirklich betroffen bist. Kritische Sicherheitslücken solltest du hingegen immer beheben.

Um diese kritischen Sicherheitslücken so schnell wie möglich zu schließen, solltest du Contao immer einigermaßen aktuell halten. Als Contao-Einsteiger solltest du zumindest regelmäßig auf das aktuelle Minor-Release bzw. die aktuelle LTS-Version aktualisieren.

Was du vor der Aufwandseinschätzung beachten solltest

Wie lange ein Contao-Update dauert hängt nicht zuletzt auch von den „äußeren Umständen“ ab. Noch bevor du eine Einschätzung für ein Update abgibst, solltest du dir ein paar Dinge genauer ansehen:

• Welche Contao-Erweiterungen werden eingesetzt? Sind die Erweiterungen mit dem Update kompatibel?
• Wurden die Templates aufwändig angepasst? Müssen die Templates nach dem Update angepasst werden?
• Welche PHP-Version wird aktuell eingesetzt? Ist für die neue Contao-Version eine neuere PHP-Version notwendig? Wie leicht lässt sich die PHP-Version hochsetzen?

Selbst diese Fragen werden dich nicht immer davor schützen, dass du mit deiner Einschätzung daneben liegst. Es sind nur die Fehler, die du am Ehesten hättest vermeiden können.

Unterschiedliche Update-Arten

Je nach Größe und Anspruch an die Erreichbarkeit der Website unterscheiden wir bei Erdmann & Freunde zwischen 3 Arten, wie wir ein Contao Update durchführen:

1. Live-Updates auf dem Live-Server

Bei kleineren Websites und kleinen Versionssprüngen (z.B. von Contao 3.4.1 auf 3.5.8) führen wir das Contao Update direkt auf dem Live-Server durch. Dafür prüfen wir die Besucherstatistik und suchen uns den Tag mit den geringsten Besuchern aus, um dann das Update in den frühen Morgenstunden oder späten Abendstunden durchzuführen.

Nach der Erstellung eines Datei- und Datenbank-Backups aktualisieren wir die Website mittels Contao Live-Update-ID. Dank des in Contao integrierten Wartungsmodus können wir das Update bequem durchführen, während der Besucher einen Hinweis auf Wartungsarbeiten erhält.

Diese Art des Updates ist dann zu empfehlen, wenn keine Probleme zu erwarten sind. Die Kosten für das Update sind überschaubar.

2. Live-Update auf einem Entwicklungsserver

Bei größeren Websites und Websites mit mehreren oder größeren Contao-Erweiterungen, führen wir das Update nicht mehr auf der Live-Umgebung, sondern auf einem gesonderten Entwicklungsserver durch. Dafür kopieren wir den aktuellen Stand des Live-Servers und übertragen ihn auf unseren Entwicklungsserver. Das kann in vielen Fällen auch einfach nur eine Kopie des Ordners mit separater Datenbank und Subdomain (z.B. dev.domain.de) sein.

Vorteil: Wir stehen bei der Durchführung des Updates nicht so sehr unter Zeitdruck. Stattdessen können wir in aller Ruhe das Update ausführen und die Website ausführlich auf Fehler prüfen. Dafür nehmen wir uns bei sehr großen Websites auch mal mehrere Tage Zeit.

Nachteil: Während der Update-Phase kann der Kunde nicht an der Website arbeiten, da wir die aktualisierte Version nach dem durchgeführten Update wieder auf den Live-Server übertragen.

Nachdem wir das Update auf dem Entwicklungsserver erfolgreich durchgeführt haben, wird dieser Stand dann zurück auf den Live-Server kopiert. Da Entwicklungsserver und Live-Server nicht selten unterschiedliche Konfigurationen besitzen, wird die Website auf dem Live-Server noch einmal getestet, bevor sie für alle sichtbar geschaltet wird.

Diese Art des Updates ist zu empfehlen, wenn Probleme zu erwarten sind, beispielsweise durch größere Versionssprünge in Contao oder Contao-Erweiterungen. Die Kosten für das Update sind schwer abzuschätzen.

3. Live-Update auf Test- und Live-Server

Bei Websites, die wir fortwährend weiterentwickeln, haben wir zusätzlich zur Live-Umgebung eine ständige Entwicklungsumgebung, die mittels Git für alle beteiligten Entwickler auch lokal aktuell gehalten wird.

So wie unter Punkt 2 beschrieben, aktualisieren wir zunächst die Entwicklungsumgebung. Der Unterschied: Der Kunde kann während des Updates wie gewohnt an der Website arbeiten. Erst nachdem wir das Update auf der Entwicklungsumgebung durchgeführt und ausführlich getestet haben, brauchen wir noch mal 1-2 Stunden, um das Update auf dem Live-Server einzuspielen und es abschließend noch mal zu testen.

Diese Art des Updates ist sinnvoll für größere Websites, die stetig weiterentwickelt werden. Mehrere Instanzen der Website müssen aktualisiert und synchronisiert werden, dafür hat der Kunde während des Updates die Möglichkeit, Änderungen vorzunehmen. Die Kosten für ein Update sind sehr unterschiedlich und reichen von 1-2 Stunden bis zu mehreren Tagen, je nachdem wie intensiv sonst an dem Projekt geabeitet wird.