Rückblick auf das erste Core-Entwicklertreffen 2026

Jedes Jahr trifft sich das Contao Core-Entwicklerteam zweimal für einen kurzen Code-Sprint von vier Tagen. Getroffen haben wir uns dieses Mal wieder im Unperfekthaus in Essen. 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.

Lukas

Besonders gefreut haben wir uns über die Teilnahme von Lukas Bableck, der unserem Aufruf gefolgt ist und sich für das 4-tägige Treffen sogar extra Urlaub genommen hat. Diesen Einsatz und sein Engagement für Contao wissen wir sehr zu schätzen!

Damit waren wir dieses Mal insgesamt neun Personen, die gemeinsam an Contao gearbeitet haben – eine starke Runde mit viel Fokus und produktiver Atmosphäre. Wer mehr über Lukas erfahren möchte, findet ihn übrigens auch im Format «Wir sind Contao».

Ausgangspunkt

Beim letzten Entwicklertreffen hatte ich noch festgehalten, dass die Frage nach der nächsten Version von Contao bewusst offen bleibt und wir die finale Entscheidung im Frühjahr 2026 treffen wollen. Entsprechend haben wir dieses Thema erneut intensiv diskutiert – und der Entscheid ist nun gefallen:

Die nächste Version wird Contao 6 heissen.

Wer regelmässig einen Blick auf unsere Roadmap geworfen hat, dürfte davon nicht völlig überrascht sein. Bereits dort war ersichtlich, dass nach Contao 5.7 nicht etwa eine Version 5.8, sondern ein möglicher Sprung auf 6.0 vorgesehen ist. Dieser Schritt ist nun offiziell bestätigt.

Wichtig ist uns weiterhin die klare Einordnung: Wir halten konsequent an Semantic Versioning fest. Sobald API-Breaks notwendig werden, führt kein Weg an einer neuen Major-Version vorbei. Gleichzeitig gilt aber unverändert unser bewährter Grundsatz der Zurückhaltung. Nur weil wir mit einer neuen Major-Version die Möglichkeit für Breaking Changes haben, heisst das noch lange nicht, dass wir sie auch unnötig einführen werden.

Auch mit Contao 6 bleibt unser Fokus auf Stabilität, Berechenbarkeit und möglichst sanften Upgrade-Pfaden. Es geht nicht um eine Revolution, sondern um eine saubere und notwendige Weiterentwicklung der Plattform – ganz im Sinne dessen, was wir bereits beim Schritt auf Contao 5 verfolgt haben.

Migration zu Output-Encoding

Wie im Bericht vom letzten Treffen bereits angekündigt, ist der wohl wichtigste Schritt in Contao 6 der Wechsel von Input-Encoding zu Output-Encoding. Endlich! Nach fast 20 Jahren Contao, tausenden (!) Zeilen vorbereitendem Code, neuen Komponenten und sorgfältig geplanten Migrationspfaden sind wir nun an dem Punkt, an dem wir diesen Schritt tatsächlich gehen können.

Damit das Ganze nochmals sauber eingeordnet ist (auch wenn wir es inzwischen wirklich oft wiederholt haben), hier die (etwas lang geratene – ich versuche halt mein Bestes) Kurzfassung, warum wir das machen müssen. Und warum Output-Encoding langfristig die einzig wirklich saubere Lösung ist:

Warum Input-Encoding ein Problem ist

Input-Encoding bedeutet: Wir «bereinigen» (oder eben fachlich richtig: «encodieren») Inhalte bereits beim Speichern. Das klingt im ersten Moment praktisch, hat aber ein paar unangenehme Nebenwirkungen:

• Kontext geht verloren.

  Ob ein Inhalt «gefährlich» ist, hängt nicht vom Inhalt selbst ab, sondern davon, wo er später ausgegeben wird: in HTML-Text, in einem HTML-Attribut, in JavaScript, in einer URL, in JSON, in einem Inline-Style usw. Ein «Encoding für alles» gibt es nicht. Jedes Zeichen kann je nach Kontext ein Steuerungszeichen sein wie z. B. < und > in HTML oder aber eben nicht. Was beim Speichern scheinbar «richtig» wirkt, ist bei der Ausgabe im falschen Kontext plötzlich wieder falsch – oder führt zu kaputtem Markup.

• Daten werden verfälscht (und manchmal doppelt encodiert).

  Ein Klassiker: Inhalte werden bereits encodiert gespeichert, später nochmals encodiert ausgegeben – und plötzlich steht im Frontend & statt & oder < statt <. Das ist nicht nur unschön, sondern macht die Weiterverarbeitung unnötig mühsam.

• Die Datenbank ist kein Ort für Ausgabe-Details.

  Die Datenbank sollte möglichst roh speichern, was der User eingegeben hat (bzw. was fachlich gemeint ist) – ohne dass wir schon beim Speichern Annahmen darüber treffen, wie und wo dieser Inhalt später gerendert wird. Input-Encoding vermengt Datenhaltung und Darstellung.

• Sicherheit ist damit nicht zuverlässig lösbar.

  Gegen XSS und verwandte Probleme hilft am Ende nur: korrektes Output-Encoding im jeweiligen Kontext. Alles andere sind Workarounds, die bei wachsender Komplexität und neuen Ausgabekanälen zwangsläufig Lücken bekommen.

Warum Output-Encoding die richtige Lösung ist

Output-Encoding bedeutet: Wir speichern Inhalte möglichst unverändert und encodieren sie erst bei der Ausgabe – passend zum konkreten Kontext. Das hat entscheidende Vorteile:

• Sicherer, weil kontextsensitiv.

  HTML-Text wird anders behandelt als HTML-Attribute, URLs anders als JavaScript oder JSON. Genau diese Kontextabhängigkeit ist der Kern von sauberer XSS-Prävention.

• Stabiler für Integrationen und Weiterverarbeitung.

  Rohdaten lassen sich sauber exportieren, transformieren, per API weitergeben oder in anderen Kanälen nutzen (Feeds, JSON, Headless-Szenarien, Suche, etc.), ohne dass man zuerst «Encoding-Schichten» wieder abtragen muss.

• Deshalb Twig!

  Twig bringt Output-Encoding standardmässig mit (Auto-Escaping). Das ist kein «Nice-to-have», sondern genau das Fundament, das man für diesen Schritt braucht.

Ein Beispiel, das aus heutiger Sicht vielleicht gerade besonders relevant ist: LLMs & API-Integrationen. Spätestens seit LLM-gestützten Workflows und API-Integrationen wird Input-Encoding noch unpraktischer: Wenn Inhalte aus externen Systemen kommen (oder von einem LLM generiert werden), lässt sich nicht sinnvoll sagen: «Schreib mir einen Text – aber bitte so, dass er genau richtig encodiert in der Contao-Datenbank landet.»

Denn das System, das den Text liefert, kennt den späteren Ausgabekontext nicht. Heute wird derselbe Inhalt vielleicht im Rich-Text ausgegeben, morgen in einem Teaser-Attribut, übermorgen als JSON für eine API oder in einem E-Mail-Template. Genau deshalb muss das Encoding an den Ort, wo der Kontext bekannt ist: zur Ausgabe.

Noch ein paar Worte zu Twig

An dieser Stelle möchte ich bewusst noch einmal eine Lanze für Twig brechen — einfach, weil das Thema verständlicherweise viele bewegt.

Ja: Bestehende .html5-Templates müssen auf Twig umgestellt werden.
Ja: Das bedeutet Aufwand. Für euch in der Community — aber ganz sicher auch für uns im Core-Team. Um es offen zu sagen: Vermutlich musste niemand so viele Templates von .html5 nach Twig migrieren wie Moritz und Martin für Contao im Core. Wir wissen also sehr genau, wovon wir sprechen.

Wichtig ist uns aber eine klare Einordnung: Twig ist nicht die Ursache der Veränderung, sondern ein zentraler Teil der Lösung!

Wir haben Twig nicht eingeführt, weil wir Lust auf Template-Umbauten hatten oder weil uns langweilig war. Der ausschlaggebende Punkt ist und bleibt das saubere Output-Encoding. Ohne eine moderne Template-Engine lässt sich dieses Ziel schlicht nicht zuverlässig erreichen und warum das wichtig ist, habe ich ja jetzt ausführlich erklärt.
Eine eigene Engine zu entwickeln, wäre weder wirtschaftlich noch technisch sinnvoll gewesen — dafür ist das Problemfeld zu komplex und zu sicherheitskritisch. Also greifen wir bewusst auf eine etablierte, battle-tested Lösung zurück.

Twig ist in der Symfony-Welt — und damit auch im Contao-Ökosystem — der de-facto Standard. Twig bringt sicheres Auto-Escaping von Haus aus mit. Und vor allem: Twig ist hervorragend erweiterbar.

Gerade dieser letzte Punkt ist für Contao entscheidend. Wir nutzen Twig nicht «von der Stange», sondern haben es tief in unsere Konzepte integriert. Müssen wir auch, weil Contao kann einfach sehr viel. Beispiele dafür sieht man überall im System:

• Contao-spezifische Funktionen für unsere eigenen Konzepte wie Insert-Tags, Inhaltselemente, URL-Generierung, Attribut-Generierung
• Zahlreiche zusätzliche Filter für CSP-Handling, Formatierungen und mehr
• Komplett eigene Sprachkonstrukte für unsere schema.org-Integration sowie das Slot-System
• Und wichtig in unserem Ökosystem: Die Möglichkeit für Extensions und der App gleichzeitig und konfliktfrei Anpassungen an denselben Templates vornehmen zu können.

Diese Erweiterbarkeit ist einer der Hauptgründe, warum Twig für Contao so gut funktioniert. Wir bekommen damit nicht nur eine moderne Template-Syntax, sondern eine stabile, zukunftsfähige Grundlage, auf der sich auch kommende Anforderungen sauber abbilden lassen.

Uns ist bewusst, dass Veränderungen immer Reibung erzeugen. Aber dieser Schritt ist wichtig — für Sicherheit, Wartbarkeit und die langfristige Weiterentwicklung von Contao. Die Entscheidung für Twig war deshalb keine Frage des Geschmacks, sondern eine sehr bewusste und pragmatische Architekturentscheidung. Und wir sind überzeugt, dass sie sich bereits heute — und noch mehr in Zukunft — auszahlt.

Die eigentliche Herausforderung: korrekte Migration der bestehenden Daten

So weit die Theorie – in der Praxis ist die grosse Aufgabe natürlich die Migration: Aktuell stehen in vielen Installationen Inhalte teilweise bereits encodiert in der Datenbank. Das müssen wir sauber und zuverlässig «entwirren», ohne dass Inhalte beschädigt werden oder plötzlich anders aussehen. Martin und ich haben deshalb an einem Konzept gearbeitet, das vorsieht, die betroffenen Felder über die gesamte 5.7er-Reihe hinweg schrittweise vorzubereiten:

In Contao 5.7.x werden die relevanten Stellen identifiziert und die nötigen Informationen über das Contao Migrations-Framework in der Datenbank festgehalten (quasi als «Merkzettel», was später wie behandelt werden muss). Beim Wechsel auf Contao 6 kann das Migrations-Framework diese Informationen dann auslesen und die eigentliche Umstellung transparent und nachvollziehbar durchführen.

Für Anwender:innen ändert sich am Ablauf damit möglichst wenig – und das ist uns wichtig. Der Update-Pfad bleibt «normal» und gut planbar:

1. Auf die neuste Contao 5.7.x aktualisieren
2. Migrationen ausführen
3. Erst danach auf Contao 6 wechseln
4. Und dort erneut die Migrationen ausführen

Also exakt das gleiche Vorgehen wie von Contao 4.x auf 5.x auch. So stellen wir sicher, dass der Sprung auf Contao 6 zwar im Bezug auf die Datenhaltung ein grosser Schritt ist, sich aber für die meisten im Alltag nicht anders anfühlt – mit klaren Zwischenschritten und ohne Überraschungen.

Ballast abwerfen: Aufräumen für Contao 6

Ihr erinnert euch vielleicht an die Grafik aus früheren Blogposts: das Contao-Schiff, das mit jedem zusätzlichen BC-Layer ein bisschen schwerer wird. Inzwischen stehen wir bei Version 5.7 — das heisst, wir hatten bereits sieben Releases Zeit, neuen Ballast an Bord zu nehmen. Entsprechend nimmt das Gewicht unseres Kahns langsam wieder zu.

Wenn wir nun ohnehin den Schritt auf eine neue Major-Version machen, nutzen wir die Gelegenheit bewusst, um erneut alte Zöpfe abzuschneiden und Contao wieder etwas zu verschlanken. Nicht radikal um der Radikalität willen, sondern gezielt dort, wo es technisch und langfristig sinnvoll ist.

Allen voran natürlich im Zuge des Wechsels auf Output-Encoding: Die .html5-Templates verschwinden — und damit auch die komplette alte Template-Engine inklusive sämtlicher Interoperabilitäts-Layer zu Twig, Spezial-Escaper wegen Input-Encoding und weiterer historisch gewachsener Komplexität. Moritz hat sich dieses Themas angenommen, und allein dieser Schritt befreit den Core von über 12’000 Zeilen Code! Code, den wir künftig nicht mehr warten müssen. Code, den wir nicht mehr an kommende PHP-Versionen anpassen müssen. Und vor allem Code, der keine subtilen Unterschiede mehr zwischen .html5- und Twig-Welt erzeugt.

Unterm Strich wird Contao dadurch spürbar schlanker, übersichtlicher und nicht zuletzt auch wieder ein Stück performanter.

Parallel dazu haben wir weitere Aufräumarbeiten auf dem Radar — beziehungsweise teilweise bereits umgesetzt. Dabei handelt es sich aber fast ausschliesslich um BC-Layer, die über den Verlauf der 5er-Reihe sauber als deprecated markiert wurden. Unser Grundsatz bleibt unverändert:

Nur so viel entfernen wie nötig — niemals so viel wie möglich.

Ein paar konkrete Beispiele für diesen pragmatischen Ansatz:

• Der system/modules-Support bleibt bestehen.

  Warum? Weil er aktuell keinen nennenswerten Wartungsaufwand verursacht und es keinen zwingenden Grund gibt, ihn jetzt zu entfernen.

• Die Umschaltmöglichkeit zwischen den alten (Contao 4.x) und neuen Inhaltselementen (ab Contao 5) bleibt erhalten.

  Auch hier gilt: Solange der Support mit vertretbarem Aufwand möglich ist, nehmen wir der Community diese Flexibilität nicht weg.

Weitere Bereinigungen wird es geben — aber immer mit Augenmass. Unser Ziel ist kein «Big Bang», sondern ein gesunder, gut wartbarer Core, der die Community zuverlässig in die nächsten Jahre trägt.

Contao 5.7 LTS

Rund um ein LTS-Release steigt die Aktivität traditionell spürbar an — und Contao 5.7 macht da keine Ausnahme. Erfahrungsgemäss lässt sich das sogar ziemlich gut visualisieren: Je näher ein Release an eine LTS-Version rückt, desto stärker nimmt die Aktivität zu. Nach dem Release flacht die Kurve wieder etwas ab, bis sie mit Blick auf die nächste LTS erneut anzieht. Durch unseren zweijährigen LTS-Rhythmus ergibt sich so ein sehr konstanter «Auf-und-ab-Flow» im Projekt.
Das betrifft übrigens nicht nur Code-Contributions, sondern ebenso die Anzahl gemeldeter Issues aus der Community. Und genau das sehen wir aktuell sehr deutlich.

Unser Treffen fand gerade einmal sechs Tage nach dem Release der Contao 5.7 LTS statt — entsprechend hoch war der Zufluss an Fehlermeldungen auf GitHub. Das überrascht wenig, denn ein grosser Teil der Community migriert erfahrungsgemäss direkt von LTS zu LTS, während Zwischenversionen deutlich weniger breit eingesetzt werden. Die Folge: Viele Installationen treffen erst mit der LTS-Version auf neue Änderungen — und entsprechend geballt kommen dann auch die Rückmeldungen.

Wir haben die Zeit am Treffen intensiv genutzt und konnten über 60 gemeldete Bugs beheben — ein starkes Ergebnis und ein wichtiger Beitrag zur Stabilität der frisch veröffentlichten LTS.
Am neuen Twig-Seitenlayout wurden nochmals spürbare Verbesserungen vorgenommen. Daraus sind einige grössere Pull Requests entstanden, an denen unter anderem Andy intensiv gearbeitet hat. Hier sieht man sehr schön, wie neben der Bugfix-Welle auch die kontinuierliche Qualitätsarbeit am Core weiterläuft.

Verbesserungen am Virtual Filesystem

Beim Virtual Filesystem (VFS) hat sich mit Blick auf Contao 6 einiges getan. Das VFS ist inzwischen seit einigen Jahren Teil von Contao und wird kontinuierlich weiter verbessert. Dieses Mal stehen zwei konkrete Verbesserungen im Fokus, an denen meine Wenigkeit gearbeitet hat.

Versionierte öffentliche Datei-URLs

Für öffentlich zugängliche Dateien die via VFS ausgeliefert werden erzeugt Contao neu versionierte URLs. D.h. es wird automatisch aus /files/downloads/about-us.pdf sowas wie /files/downloads/about-us.pdf?version=d78fda63144c5c84.

Der zusätzliche Versions-Parameter sorgt dafür, dass sich die URL automatisch ändert, sobald sich die Datei ändert. Das verbessert vor allem das Caching-Verhalten erheblich: Browser und Proxies können Dateien aggressiv cachen, ohne dass Anwender:innen veraltete Inhalte sehen.

Geschützte Dateien: deutlich einfacher und sicherer

Bisher mussten sich Entwickler:innen selbst darum kümmern, geschützte Dateien korrekt auszuliefern und die Berechtigungen zu prüfen. Zwar gab es mit dem Service contao.filesystem.file_download_helper bereits eine Unterstützung, dennoch musste die Logik jeweils im eigenen Controller implementiert werden.

Mit Contao 6 wird das deutlich einfacher.

Neu reicht es, beim Aufruf von $vfs->generatePublicUri() die passende TemporaryAccessOption zu übergeben — den Rest übernimmt Contao automatisch. Das reduziert nicht nur Boilerplate-Code, sondern sorgt auch für ein konsistentes und sicheres Verhalten über alle Integrationen hinweg.

Fritz hat dieses neue Verfahren bereits im Player-Inhaltselement integriert. Damit lassen sich künftig auch geschützte Videos sauber und kontrolliert ausliefern — ein häufig gewünschtes Szenario, das nun ohne Speziallösungen möglich ist.

Kurz gesagt: Das VFS wird mit Contao 6 nicht nur sicherer, sondern auch deutlich angenehmer in der Anwendung — sowohl für Erweiterungen als auch für die Core-Features selbst.

Diverses

Dieser Blogpost ist bereits ziemlich lang — und meine Energie schwindet — dabei gäbe es noch deutlich mehr zu erzählen. Wie so oft gilt aber: Nicht alles, woran wir arbeiten, ist bereits spruchreif, und manches gehört schlicht (noch) nicht in die breite Öffentlichkeit.

Ein paar erwähnenswerte Punkte möchte ich aber trotzdem festhalten:

• Moritz hat weiteren HTML-Code aus unseren DataContainer-Klassen in Twig-Templates ausgelagert. Ein weiterer Schritt in Richtung klarerer Trennung von Logik und Darstellung.
• Leo hat sich erneut um die PHPUnit-Kompatibilität mit neueren Versionen gekümmert. Das entwickelt sich inzwischen fast schon zur festen Routine bei unseren Treffen — aber eine wichtige.
• Bei den Abhängigkeiten gibt es ebenfalls Neuigkeiten: Die minimale Version von Doctrine DBAL wird auf v4 angehoben.
• Auch die PHP-Minimalversion wird auf mindestens PHP 8.4 gesetzt. Damit können wir unter anderem native Lazy Objects im Dependency Injection Container sowie moderne Proxy-Mechanismen in Doctrine ORM nutzen.
• Der Backend-Theme-Support wird entfernt. Parallel arbeitet Sebastian weiterhin mit Hochdruck an der Modernisierung unserer Backend-Build-Chain und wirft konsequent ein MooTools-basiertes Skript nach dem anderen über Bord. Für Contao 6 könnte es zeitlich zwar knapp werden — rund 80 % sind bereits geschafft. Aber ihr kennt das Pareto-Prinzip.
• Dave hat den Umbau von Frontend-Modulen zu Inhaltselementen weiter vorangetrieben und sich endlich auch unserer alten Email-Klasse angenommen. Diese wird in Contao 6 deprecated und der Core hat dann vollständig auf den Symfony Mailer umgestellt.
• Lukas hat daran gearbeitet, nativen Support für Page Images inklusive og:image-Tags direkt im Core umzusetzen — ein Feature, das viele freuen dürfte.
• Ebenfalls von Lukas: ein neuer Filter im Template Studio, mit dem sich überschriebene Templates schneller finden lassen. Grossartig!

Übrigens: Bei diesem Treffen haben wir über 100 (!) Pull Requests erarbeitet – mehr als 70 davon sind bereits gemerged. Parallel laufen noch zahlreiche Proof-of-Concepts, neue Ideen und weitere Baustellen für die Contao-6-Reihe. Für die kommenden Monate und Treffen ist also mehr als genug Stoff vorhanden.

Zum Schluss noch ein herzliches Dankeschön an unser Projektteam für die mittlerweile fast schon traditionelle Snackbox — die ist jedes Mal ein Highlight!

Ein besonderer Dank geht an Hagen, der extra seinen 3D-Drucker angeworfen und passende Contao-Ausstechförmchen gedruckt hat. Marcus’ Frau und Tochter haben diese dann mit viel Liebe in Form köstlicher Contao-Kekse zum Leben erweckt — und uns damit wirklich begeistert! Und auch an Marcus selbst ein grosses Dankeschön für den handgeschriebenen Brief, über den wir uns sehr gefreut haben. Vielen Dank euch allen für die Mühe und die tolle Überraschung, wir wissen das sehr zu schätzen!

Fotos findet ihr im Anhang zum Blogpost.

That's all Folks!

– Yanick