Contao-News

Jedes Jahr trifft sich das Contao Core-Entwicklerteam zwei Mal für einen kurzen Code-Sprint von drei Tagen. Wer meinen Rückblick vom letzten Treffen gelesen hat weiss, dass wir uns mittlerweile in Colmar in Frankreich treffen.

Wie auch schon letztes Jahr hat uns Corona aber auch dieses Jahr einen kleinen Strich durch die Rechnung gemacht. So sind mit "wir" dieses Mal alle ausser meiner Wenigkeit gemeint. Ich musste auf Umarmungen verzichten und habe dem Treffen via Videotelefonie aus der Kontaktisolation beigewohnt.

Trotzdem bin wieder ich es, der versucht, das Treffen für euch zusammenzufassen. Immer noch der festen Überzeugung dadurch eine gewisse Transparenz, was die Zukunft von Contao angeht, zu schaffen. Die Entwicklertreffen sind für Contao entscheidend und daher mache ich wie immer darauf aufmerksam, dass die Contao Association diese Treffen finanziert. Als Supporter kannst du deinen Teil dazu beitragen.

Und nun zum Elefanten im Raum.

Contao 5

Es ist soweit, wir sprechen über eine neue Major-Version. Traditionell weckt eine neue Versionsnummer an der vordersten Stelle auf der einen Seite grosse Erwartungen. Auf der anderen Seite schürt sie Ängste:

• "Werde ich die Installationen von all meinen Kunden updaten können?"
• "Wir haben so viele Erweiterungen in unserer Agentur, müssen wir überall bei null anfangen?"
• "Irgendwie haben wir uns erst gerade an Contao 4 gewöhnt, jetzt kommt Contao 5?"

Ich denke, ihr kennt diese und weitere Fragen nur allzu gut. Ich sehe es deshalb als meine Aufgabe, euch in diesem Blogpost sowohl die Ängste zu nehmen, als auch die Erwartungen zu relativieren.

Eine der Aufgaben für uns als Core-Team ist es, für die Zukunft zu planen und das bedeutet manchmal auch, vielleicht eher unbequeme und schwierige Entscheidungen zu treffen. Ein Beispiel für eine solche Entscheidung dürfte die Umstellung auf Symfony und Composer mit Contao 4 gewesen sein, welche wir 2015 getroffen haben. Ja, du hast richtig gelesen: Contao 4 ist bereits sieben Jahre alt! Den Entscheid haben wir keine Sekunde bereut. Wir haben dadurch unzählige Funktionen einbauen können, die ohne diesen kompletten architektonischen Umstieg undenkbar gewesen wären. Wir hätten wahrscheinlich heute weder Zweifaktor-Authentifizierung, noch Kommandozeilenbefehle, HTTP-Caching, Twig oder automatisierte Tests. Mittlerweile haben wir tausende Tests und die Software-Qualität von Contao steigt mit jedem Release.

Es ist mir ein grosses Anliegen, dass jede Anwenderin und jeder Anwender von Contao den Entwicklungsprozess versteht und unsere Argumentationen und Entscheide nachvollziehen kann.

Ausgangslage

Ich werde nachfolgend ein paar Fakten auflisten, damit du dir ein besseres Bild der Ausgangslage machen kannst:

• Das aktuelle Core-Team besteht aus 8 Entwicklern, wovon allesamt auf freiwilliger Basis an Contao arbeiten. Die einzige Ausnahme ist Leo, der dank der Contao-Partner einen Teil seiner Arbeitszeit für Contao verwenden kann.
• Was ganz gerne vergessen geht: Geschätzt 80 % der Arbeitszeit an Contao betrifft Wartungsarbeiten. Regelmässige Bugfixes, Kompatiblität zu aktuellen Symfony- und PHP-Versionen, Anpassungen an Continuous Integration (Tests, Coding Style etc.). Das sind alles Dinge die für Anwender:innen unsichtbar sind und oftmals als selbstverständlich wahrgenommen werden. Natürlich erwarten alle, dass Contao einfach mit den neusten PHP-Versionen kompatibel ist. Das bedeutet aber jede Menge Arbeit für das Core-Team. Wenn also 80 % für Wartungsarbeiten gebucht sind, können nur 20 % in die Weiterentwicklung von Contao investiert werden. Ja, das Pareto-Prinzip lässt sich überall anwenden.
• Contao 4 ist Contao 3 mit Symfony-Unterbau und seither wird in jeder neuen Version von Contao 4 ein bisschen was vom alten System umgebaut und verbessert. Ein CMS wie Contao, das sich über viele Jahre entwickelt hat, baut man nicht mal eben so von Grund auf neu. Dafür hat uns damals die Manpower (oder Womanpower) gefehlt und an dieser Situation hat sich bis heute nichts geändert. Der einzige Weg Contao zu modernisieren sind kleine Schritte mit jeder neuen Version.
• Mit Contao 4 haben wir uns zu Semantic Versioning verpflichtet. In einfachen Worten bedeutet dies: Wenn eine Entwicklerin Code für Contao 4.4 geschrieben hat, dann muss dieser auch noch in Contao 4.13 funktionieren. Erst in Contao 5 ist das Entfernen von Schnittstellen erlaubt. Mit jeder neuen Version von Contao sammeln sich folglich auch neue sogenannte "Backwards-Compatibility-Layer" an. Also Ebenen an Code, welche die alten Schnittstellen mit den neuen Schnittstellen kompatibel halten, damit der alte Code weiterhin funktioniert. Wir nennen diese kurz einfach nur "BC-Layer" und ich werde das nachfolgend so verwenden.
• Contao 4.13 enthält grob geschätzt 700 solcher BC-Layers. Anders ausgedrückt haben wir also seit Contao 4.0 an 700 Stellen Verbesserungen angebracht und dafür gesorgt, dass der alte Weg immer noch funktioniert. 700 ist eine unglaublich hohe Zahl, wenn man bedenkt, dass sie über nur 13 Versionen eingeführt wurden. Nach Adam Riese ergibt das über 50 Verbesserungen in jeder Contao-Version und wir sprechen hier nur von Entwickler-Schnittstellen. Über Verbesserungen für Anwender wollen wir an dieser Stelle erstmal gar nicht sprechen.
• Contao 4.13 besteht ohne Abhängigkeiten wie Symfony und Co. aus ungefähr 270.000 Zeilen eigenem PHP-Code. Dazu kommen noch jede Menge Zeilen Code in Templates, CSS und JavaScript.

Contao 5 ist nur eine Zahl

Die Ausgangslage dürfte aufzeigen, was das Problem ist: Der Wartungsaufwand ist immens und mit jeder neuen Contao-Version steigt er an, da plötzlich sowohl der neue Code als auch der dazugehörige BC-Layer gepflegt werden müssen. Wenn also beispielsweise eine neue PHP-Version veröffentlicht wird, dann müssen wir beides kompatibel halten.

Mittlerweile schreiben wir das Jahr 2022, Contao 4 wird im Juni sieben Jahre alt und wir stehen vor einem riesgen Berg an BC-Layern. Oder in meinen Worten ausgedrückt: Leute, wir ersticken bald in altem Code und brauchen dringend Luft! Wir müssen endlich einen Grossteil von diesem alten Ballast von Bord werfen, ansonsten können wir unser Schiff irgendwann nicht mehr warten und es würde sinken.

Das Entfernen dieser BC-Layer zwingt uns gemäss Semantic-Versioning dazu, die nächste Version als 5.0 zu veröffentlichen.

Auf der anderen Seite fällt auch nicht plötzlich Manpower vom Himmel, nur weil man die Versionsnummer von 4 auf 5 ändert. Contao 5 wurde nicht jahrelang im Hintergrund von bisher unbekannten Freiwilligen auf ehrenamtlicher Basis entwickelt und wird uns jetzt überraschenderweise plötzlich eine API, ein komplett neues Backend oder <füge deinen Wunsch hier ein> bringen. Es sind immer noch dieselben 8 Core-Entwickler plus Community-Mitglieder, die mit der Wartung und Weiterentwicklung von Contao 4 beschäftigt waren und weiterhin sind.

Contao 5 ist einfach die nächste Iteration. Wir werden den eingeschlagenen Weg weiterverfolgen und die Code-Basis Schritt für Schritt modernisieren. Contao 5 ist also nur eine Zahl. Es ist quasi Contao 4.14 ohne einen Grossteil der BC-Layer und deswegen Version 5. Punkt.

Ein bisschen langweilig? Ja, und darauf sind wir stolz. Contao ist nicht fancy und folgt jedem neuen Trend, auch wenn die Verlockung dazu natürlich auch im Core-Team regelmässig aufblitzt. Wir wissen um die Bedürfnisse unserer Agenturen, für die Stabilität und Kontinuität viel wichtiger sind, als die Auswahl aus 20 verschiedenen Slider-Skripten wovon die Hälfte in einem Jahr wieder nicht mehr cool ist.

Contao ist zuverlässig, realistisch und setzt auf Qualität und Kontinuität statt Fanfaren und Konfetti mit jedem Release. Böse Zungen würden behaupten, Contao ist halt einfach ziemlich Deutsch (und das schliesst die deutschsprachigen Nachbarländer mit ein).

Entsprechend umfassen die aktuellen Arbeitspakete vor allem das Entfernen von BC-Layern im aktuellen Entwicklungszweig für Contao 5. Zum Zeitpunkt dieses Blogposts enthält dieser bereits rund 30.000 Zeilen (!) weniger, als sein Pendant für Contao 4.13. Das bedeutet bereits jetzt eine Reduktion der Code-Zeilen um über 10 % und wir sind noch längst nicht am Ziel.

Keine Contao 3 Module mehr?

Entsprechend dem Credo auf Kontinuität zu setzen, entfernen wir nicht einfach sämtliche BC-Layer, sondern besprechen diese im Team und versuchen die Auswirkungen abzuschätzen. Würden wir den Support von alten Contao 3 Modulen in system/modules komplett entfernen, würde sich der Wechsel auf Contao 5 extrem aufwändig gestalten. Das wollen wir verhindern, entsprechend wird dieser BC-Layer in Contao 5 noch nicht entfernt werden. Allerdings wird es dann eben auch nicht ganz ohne Anpassungen funktionieren. Wir müssen Kompromisse machen und von den Erweiterungsentwickler:innen erwarten, dass sie ihre Erweiterungen ebenfalls Schritt für Schritt modernisieren, so wie das Contao selbst auch tut.

Welche Anpassungen alle bei der Veröffentlichung von Contao 5 nötig sein werden, dokumentieren wir in der dafür zuständigen UPGRADE.md, die sich im Entwicklungszweig von Contao 5 befindet.

Wie kann ich mich vorbereiten?

Grundsätzlich ist es so, dass alle Entwickler:innen ihre Erweiterungen nach eingesetzten BC-Layern durchsuchen können. Die wichtigsten Informationen dazu finden sich in der DEPRECATED.md im jeweiligen Entwicklungszweig und werden auch im Symfony-Profiler bei den "Logs" im Tab "Deprecations" aufgelistet.

Ausserdem ist es bestimmt auch nicht verkehrt, den Entwicklungen im Monorepository zu folgen.

In other news

Nebst dem Entfernen von BC-Layern haben sich die 8 Entwickler wie folgt beschäftigt:

• Martin: Schnellere Functional-Tests, Verbesserungen am reviseTable-Prozess, SQL-Theme-Import im Backend (Install-Tool abschaffen), contao:migrate Kommando verbessern (Install Tool-abschaffen)
• Leo: Verbesserungen am Backend-Theme, Integration von contao/test-case in das Monorepository
• David: Implementierung des neuen Symfony-Security-Systems, das in Symfony 5.1 als experimental eingeführt wurde
• Fritz: Entfernung des <base> Tags und absolute Links überall
• Andy: Entfernen von MooTools im Contao-Backend und Ersatz durch Vanilla-JS
• Jim: Generated Doctrine-Entities, die nach wie vor unser Plan für den langfristigen Ersatz von Models sind, PHP8 Attributes
• Moritz: Twig, Umbau Inhaltselemente auf Fragments
• Yanick: Permissions in den DC_* Treibern für die langfristige Umstellung von den checkPermission() onload_callbacks auf Security Voter

Insgesamt sind am Entwicklertreffen bereits über 50 Pull Requests entstanden und wie immer hat es für viele Impulse gesorgt, die in weiteren Pull Requests resultieren werden.

That's all, folks!

Ich hoffe, ich konnte dir mit diesem Blogpost deine Ängste nehmen und aufzeigen, warum Version 5 am Ende des Tages nur eine Zahl ist. Ich würde mich freuen, dich auf dem Contao Camp in Potsdam zu treffen.

• Yanick