Rückblick auf das erste Core-Entwicklertreffen 2025

Jedes Jahr trifft sich das Contao Core-Entwicklerteam zweimal für einen kurzen Code-Sprint von drei Tagen. Getroffen haben wir uns dieses mal in Kassel. Obligatorischer Hinweis: Die Entwicklertreffen sind für die Weiterentwicklung von 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.

Sebastian

Nachdem Sebastian Zoglowek bereits unser letztes Treffen bereichert hat, ist er auch dieses Mal unserem Aufruf gefolgt und hat zusammen mit uns an Contao 5.6 gearbeitet. Vielen Dank, lieber Sebastian, dass du dir das erneut freiwillig angetan hast!

Ausgangspunkt

Beim letzten Treffen haben wir den Fokus auf das Backend gelegt. Contao verfügt jetzt über eine systemweite Backend-Suche, ein Kontextmenü, eine verbesserte «Mehrere bearbeiten»-Funktion, ein Template-Studio (dessen Ausmasse ich einfach immer noch krass finde - was für eine Leistung!) und etliche Verbesserungen im Zusammenhang mit der Barrierefreiheit. Bei jedem Treffen stellt sich die gleiche Frage: «What’s next?» Und ebenfalls wie bei jedem Treffen ist der Berg an Arbeit riesig und die zur Verfügung stehende Zeit zu gering. Also setzt man sich hin und diskutiert, was man über die nächsten zwei, drei Versionen erreichen möchte. Dabei versuchen wir immer, dass sich die technisch notwendigen Aufgaben und User-Features ein bisschen die Waage halten. In demer letzten Version haben wir fast ausschliesslich User-Features gebaut, von daher müsste jetzt wieder etwas mehr Fokus auf dem technischen Unterbau liegen. Gemäss unserer - nicht verbindlichen - aktuellen Roadmap, ist Contao 6 für nächstes Jahr geplant. Und wie bereits bei Contao 5 wird es hier primär darum gehen, dass wir den neu angehäuften Stapel an Rückwärtskompatibilität entfernen können und wieder etwas schlanker werden. Wir wissen noch nicht, ob wir Contao 6 wirklich nächstes Jahr releasen werden. Das wird sich zeigen. Aber auf jeden Fall erwarten wir, dass der Umstieg von Contao 5 auf Contao 6 kein Problem darstellen wird. Die neue Major-Version ist wie immer eine Konsequenz von Semantic Versioning, wer diese Blogpostreihe und Contao schon länger verfolgt, wird sich mittlerweile an das Versionierungsschema gewöhnt haben. Kontinuität ist eine unserer grossen Stärken. Das ist so und das bleibt so. Aber natürlich gab Contao 6 Anlass zu Diskussionen. «Was könnten wir endlich loswerden?», «Was wird uns ohnehin noch länger begleiten?», «Was bereitet uns aus Sicherheitsaspekten Sorgen?», «Was wollen die Anwender und Anwenderinnen und was wollen wir?», «Was können oder müssen wir den Anwendern und Anwenderinnen zumuten, weil es keine Alternative gibt?», etc.

Entschieden haben wir, dass wir in näherer Zukunft gerne endlich dieses Input-Encoding-Thema loswerden müssen. Die Voraussetzung dafür ist klar: Twig. Unsere «html5»-Templates encodieren nichts per Default und bieten daher unausweichlich Potential für XSS-Lücken. Twig - oder de-facto wohl jede Template-Sprache - dreht das um und encodiert den Output automatisch. Die Inhaltselemente haben wir bereits in Contao 5 auf Twig umgestellt. Der nächste Schritt wären also die Frontendmodule.

Frontendmodule und Twig - bye, bye Frontendmodule

Dieses Problem hätte man relativ einfach lösen können: Wir hätten einfach alle mod_*.html5-Templates auch als Twig-Templates zur Verfügung stellen können. Aber es gibt ja noch eine weitere Aufgabe, denn die meisten Core-Frontendmodule sind auch noch alte Module die noch keine richtigen Controller sind, keine Dependency Injection nutzen, voller Hooks und legacy Code sind. Aber auch ansonsten gibt es in vielen Frontendmodulen fragwürdige Einstellungsmöglichkeiten, die vielleicht irgendwann mal Sinn ergeben haben, das aber mittlerweile nicht mehr tun. Oder Module wie «Zufallsbild», die komplett inkompatibel mit dem HTTP-Cache sind etc. pp. Gealterte Software eben. Entsprechend sind wir relativ schnell davon weggekommen, einfach nur neue Templates für die bestehenden Module zu bauen. Das wäre im Gesamtkonzept nicht zielführend bzw. einfach schlecht investierte Zeit. Also welchen Weg gehen? Genau, wir bauen einfach neue und lassen die bestehenden unangetastet. Irgendwann, wenn die Zeit reif ist, entfernen wir dann die alten. Das ermöglicht eine schrittweise Migration, ist rückwärtskompatibel und das haben wir bereits bei den Inhaltselementen so gemacht.

Aber, wozu überhaupt noch Frontendmodule bauen? Viele davon haben wir ja eigentlich bereits als Inhaltselemente mit Twig: Bilder, Links, HTML, etc. Auch viele Extensions bieten ihre Elemente jeweils als Inhaltselement und Frontendmodul an. Und wozu? Damit man sie sowohl in Artikeln als auch im Seitenlayout einbinden kann. Aber warum diese Unterscheidung? Eine HTML-Sitemap z. B. wird in den allermeisten Seiten nur einmal auf einer Seite ausgegeben. Warum ist das ein Frontendmodul statt ein Inhaltselement? Und wer sagt, dass ich ein Navigationsmenü nur im Layout platzieren möchte, nicht aber direkt auf einer Seite? Ach so, dafür gibt es ja das Inhaltselement «Modul» womit man dann doch wieder ein Frontendmodul auf eine Seite platzieren kann.

Deswegen haben wir uns dazu entschieden, in Zukunft keine Frontendmodule mehr zu bauen und diese irgendwann sterben zu lassen. Stattdessen können jetzt überall Inhaltselemente direkt eingebunden werden – sogar im Seitenlayout. Diese werden einfach auf dem Theme erstellt, genauso wie das auch für Frontendmodule aktuell der Fall ist. Irgendwann haben wir dann nunmehr Inhaltselemente und wie die wo eingesetzt werden, darüber entscheidet jeder Anwender und jede Anwenderin selber - die Berechtigungen erledigen den Rest. Dies wird bereits ab Contao 5.6 möglich sein, eine Aufgabe, mit der ich mich beschäftigt habe.

Dave hat bereits das Zweifaktor-Frontendmodul als neues Inhaltselement mit Twig umgebaut und Fritz hat angefangen, das Login-Modul umzuschreiben, denn…

Passkeys im Frontend

In der letzten Version hat Fritz uns Passkeys für das Contao-Backend geschenkt. Konsequenterweise gehört diese Funktion natürlich nun auch noch im Frontend zur Verfügung gestellt. Das ist immer ungleich viel mehr Aufwand, weil Backend gibt es ja immer nur eins. Im Frontend gibt es aber verschiedene Seitenbäume, dynamische URLs und ggf. eben auch mehr als nur ein Frontendmodul. Frontendmodul? Nein, natürlich nicht. Die Passkeys werden im Frontend nur noch als neues Inhaltselement mit Twig zur Verfügung stehen. Ob ihr es dann im Seitenlayout einbindet oder in einem Artikel auf einer Seite, bleibt euch überlassen. Neue Welt!

Neues Seitenlayout mit Twig und Slots

Apropos Seitenlayout. Auch dort befinden sich haufenweise Einstellungsmöglichkeiten, die nicht mehr zeitgemäss sind. Und am Schluss entscheidet das fe_page.html5 darüber, was wo ausgegeben wird. Wisst ihr noch damals? Holy Grail? Auch das muss geändert und durch eine modernere, Twig-basierte Variante ersetzt werden. Moritz hat sich damit beschäftigt und ab Contao 5.6 wird es deshalb möglich sein, zwischen der aktuellen Seitenlayout-Variante und der neuen zu wählen. Übrigens: Custom Sections werden dann nicht mehr virtuell angelegt, sondern Contao weiss einfach, welche Slots in dem ausgewählten Twig-Template zur Verfügung stehen und nur zu diesen können dann auch Inhaltselemente (und bis auf Weiteres Frontendmodule) ausgewählt werden. Die Unterstützung für Slots in Twig haben wir bereits in einer vergangenen Contao-Version eingeführt - ich hatte darüber auch im Rückblick auf das Entwicklertreffen berichtet. Bye, bye Fehlerquelle.

PHPUnit 11

Nun zu einem wirklich lästigen Thema, aber gleichzeitig auch einer Arbeit, auf die wir als Team stolz sein dürfen. Wusstet ihr, dass Contao mittlerweile etwa 5.500 automatisierte Tests mit knapp 40.000 Assertions (Vergleiche mit erwartetem Wert vs. effektivem Wert) enthält? Unsere Testsuite lief bis anhin immer noch auf PHPUnit 9. Ein Zustand, den wir dringend ändern mussten, denn auch hier gilt, dass alte Software irgendwann nicht mehr gewartet wird und je länger man mit dem Update zuwartet, desto komplexer und aufwändiger das Update. Denn in der Zwischenzeit kommen ja auch immer wieder neue Funktionen mit neuen Tests dazu. Die Krux am Update: PHPUnit wurde einer ziemlich heftigen Verschlankungskur unterzogen. Viele Funktionen, auf die wir uns verlassen haben, wurden umgeschrieben oder im schlimmsten Fall sogar komplett entfernt. Ich denke, man muss selber Entwickler:in sein um zu verstehen, wie viel Aufwand da drin steckt aber im Endeffekt haben Andy, Moritz, Martin und ich zusammen an diesem Mammut-Projekt gearbeitet. Das hat uns sicher locker 20 Stunden Arbeit beschert. Nach über 150 Commits und über 300 geänderten Dateien haben wir es jetzt geschafft! Die ganze Testsuite läuft auf PHPUnit 11.5 und ist grün. Dabei haben wir auch viele Tests verbessert, umgeschrieben und sind ganz nebenbei auch die Symfony PHPUnit-Bridge losgeworden.

Das wäre ein Beispiel für eine Aufgabe, die kein(e) Anwender(in) jemals zu Gesicht bekommen wird aber für das Projekt von essenzieller Bedeutung ist. Wer weiss, ob wir ohne das Entwicklertreffen diesen Umstieg jemals geschafft hätten. Dein Sponsoring der Contao Association, die diese Treffen finanziert, ist also wirklich, wirklich wichtig!

Metadata-Overwrite

In den vergangenen Contao-Calls wurde oft diskutiert, dass die «Metadaten überschreiben»-Funktion bei den Inhaltselementen für Downloads etwas unpraktisch ist. Denn meistens ist es ja so, dass man die Metadaten in der Datei pflegt, aber für die Ausgabe an einer bestimmten Stelle vielleicht den Titel ändern möchte. Oder die Bildunterschrift. Aber nicht einfach komplett alles, so wie es jetzt ist. Entsprechend werden wir das in Contao 5.6 umstellen, sodass die Metadaten zusammengeführt werden. Also wurde etwas überschrieben, so wird das genommen, ansonsten wird auf die Informationen der Datei-Metadaten zurückgegriffen. Für den Fall, dass wirklich bspw. eine Bildunterschrift mit «Nichts» überschrieben werden soll, gibt es einen neuen {{empty}} Insert-Tag.

Reloadable DCAs

Das ist ein Thema über das sich Entwickler:innen freuen werden: Dank Martin wird es in Zukunft möglich sein, DCAs im selben Request mehrfach zu laden und zurückzusetzen. Soweit mir bekannt, dürfte das das letzte Hindernis gewesen sein, das uns daran gehindert hat, DCA-Aktionen nachzubilden. Daher sollte es jetzt möglich sein, beispielsweise einen Aufruf an /contao?do=news&id=123&table=tl_content&act=edit zu simulieren, sodass die DCA-Konfiguration entsprechend geladen wird, ohne dass der Request effektiv dieser URL entsprechen muss.

Barrierefreie Navigationen

Barrierefreie Navigationen zu erstellen ist nicht ganz einfach und viele Dinge müssen beachtet werden. Denken wir nur an die Tastatur-Navigation, übersetzte ARIA-Labels, Focus-Trap auf mobilen Endgeräten, Sprunglinks etc. Sebastian und Leo haben bereits in den vergangenen Contao-Versionen daran gearbeitet, unsere Backend-Navigationen barrierefrei(er) zu machen und auch für die 5.6 hat Leo noch einmal Verbesserungen angebracht, sodass man im Backend bspw. direkt zum Inhalt springen können wird. Sebastian seinerseits arbeitet daran, dem Core auch für das Frontend entsprechende Templates und Javascript-Lösungen mitzuliefern, damit hier für gewisse Anwendungsfälle ggf. mehr out-of-the-box-Lösungen existieren werden.

Diverses

• Sebastian und Leo haben das Blur-Handling im gesamten Backend verbessert
• Fritz hat das Scroll-Verhalten mit Turbo in Contao 5.5 verbessert
• Sebastian hat die Accessibility-Features des ACE-Editors ab Contao 5.3 aktiviert
• Dave hat die Erreichbarkeit der Zweifaktor-Informationen im Backend verbessert
• Fritz hat das Lock-Handling für Cronjobs verbessert
• Martin hat das ESI Handling bei Insert-Tags verbessert
• In Contao 5.6 werden dank Martin in den Bildgrössen weitere Konvertierungen zwischen Bildformaten zur Auswahl angeboten
• Sebastian hat wieder einiges an Mootools im Backend auf Stimulus-Controller umgebaut bzw. sich damit beschäftigt, was er in den kommenden Monaten gerne noch umbauen möchte
• Andy hat sich mit Dateiberechtigungen auseinandergesetzt. Diese werden höchstwahrscheinlich auch noch in die DC_Folder kommen aber würden auch eine wichtige Grundlage dafür bieten, vielleicht irgendwann einen alternativen Dateimanager zu bauen

Auch dieses Jahr wurden wir vom Projektteam mit einem «Care-Paket» überrascht. Darin befanden sich nicht nur Süssigkeiten, sondern man sieht auch, dass es ein paar kreative Köpfe in unseren Reihen gibt. Ich hänge dem Blogpost ein paar Bilder an. Vielen herzlichen Dank, lieber Marcus und alle, die sich ebenfalls daran beteiligt haben - wir haben uns sehr darüber gefreut!

Ansonsten möchte ich nochmal auf die Contao Konferenz vom 25. - 26.09.2025 in Düsseldorf aufmerksam machen. Ich wünsche mir, dass möglichst viele den Weg an den Rhein finden und mit uns auf das Erreichte anstossen!

That's all Folks!

– Yanick