Contao-News

Jedes Jahr trifft sich das Contao Core-Entwicklerteam zwei Mal für einen kurzen Code-Sprint von drei Tagen. Da zur Zeit vier Entwickler aus der Schweiz kommen, findet das Treffen jeweils ein bisschen ausserhalb von Zürich... halt, Moooment! Vieles ist anders in diesem Jahr.

Zum Beispiel schreibe ich gerade über das erste Entwicklertreffen im 2021, wo ich doch eigentlich über das zweite schreiben sollte. Corona stellt mal wieder alles auf den Kopf. So konnten wir uns zu Beginn dieses Jahres leider nicht treffen. Ein – wie ich finde – schmerzlicher Ausfall. Contao 4.12 hätte bestimmt noch einiges mehr zu bieten gehabt, hätten wir uns persönlich treffen können. Gleichzeitig beweist das aber auch, wie wichtig die Entwicklertreffen für Contao sind. Ich nutze daher die Gelegenheit und mache wie immer darauf aufmerksam, dass die Contao Association unsere Treffen finanziert. Als Supporter kannst du deinen Teil dazu beitragen.

Getroffen haben wir uns dieses Jahr nicht in der Region Zürich, sondern in Colmar, Frankreich. Der Grund dafür ist relativ einfach: Mit von der Partie war, zusätzlich zu den sieben Core-Entwicklern, dieses Mal auch Moritz Vondano. Ihr kennt ihn vielleicht von den neusten Contao.random()-Sendungen auf Contao TV oder durch seine Arbeit an der Twig-Integration in Contao 4.12. Mit anderen Worten: Wir brauchten einfach etwas mehr Platz und haben diesen (ironischerweise) mitten in der schmucken Stadt im Elsass gefunden.

Ausgangslage

Zur Freude einer grossen Mehrheit unserer User steht uns wieder eine neue LTS-Version bevor! Contao 4.13 LTS wird die nächste und zugleich letzte Contao 4er Version sein. Als Fundament wird uns Symfony 5.4 LTS dienen und die Mindestversion von PHP wird neu bei PHP 7.4 liegen.

Wie bei jeder LTS-Version gilt: Stabilität und Sicherheit haben absoluten Vorrang. Entsprechend wird es auf keinen Fall neue experimental Features (zurzeit ist Twig unsere einzige experimentelle Integration) geben. Dennoch wird die neue Version vollgepackt mit neuen Funktionen sein, zu denen ich gleich noch etwas mehr schreiben werde.

Noch ein paar wichtige Worte zu Contao 5: Wir haben es bereits mehrfach kommuniziert, aber ich will es gerne erneut klarstellen. Contao 5 ist primär einfach eine Zahl und es gibt keinen Grund zur Sorge. Contao bleibt Contao und wir erfinden das Rad nicht neu. Wir sind uns unserer Verantwortung bewusst und wissen um die grosse Stärke der Beständigkeit und Planbarkeit von Contao.

Wir haben uns mit dem Erscheinen von Contao 4 zur Einhaltung von Semantic Versioning verpflichtet. Das bedeutet, wir müssen die Rückwärtskompatibilität bis zurück zu Contao 4.0 stets unterstützen. Contao 4 ist allerdings bereits über sechs Jahre alt (eine freundliche Erinnerung daran, dass wir alle älter werden) und mit jeder neuen Version die erscheint, müssen wir mehr Altlasten mitpflegen. Jede weitere Altlast erhöht den Wartungsaufwand für das Core-Team und irgendwann lässt sich dieser einfach nicht mehr rechtfertigen. An diesem Punkt sind wir jetzt angekommen und es wird Zeit, ein paar alte Zöpfe abzuschneiden.

Aber keine Sorge, wir entfernen nicht den Support für Contao 3-Module und werden auch nicht den Contao Manager wegschmeissen oder sonstige Massnahmen ergreifen, von denen ihr nachts Schweissausbrüche kriegt. Es werden einige Anpassungen nötig sein, aber wir werden dafür sorgen, dass sie im Rahmen des Machbaren sein werden.

Da wir also gewisse Kompatibilitätsebenen entfernen werden, zwingt uns Semantic Versioning dazu, die vordersten Zahl (die «Major Version») zu erhöhen. Und genau das ist es, was Contao 5 für die allermeisten unter euch sein wird: Einfach nur eine andere Zahl.

Also keine Panik, alles wird gut!

Insert-Tags

Insert-Tags sind die Hass-Liebe für uns in Contao. Für Anwenderinnen und Anwender sind sie einfach super praktisch, aber die Tatsache, dass sie sich immer und überall (Stichwort: kontextunabhängig) verwenden lassen, lässt uns immer wieder über potenzielle Angriffslücken nachdenken.

Ein einfaches Beispiel gefällig? Nehmen wir mal an, unsere Seite trägt den Titel des grossartigsten Sängers, den die Welt je gesehen hat: Farrokh "Freddie Mercury" Bulsara

Nun kennen wir alle den {{page::pageTitle}} Insert-Tag und ich werde euch jetzt zeigen, weshalb der Kontext, in dem er genutzt wird, wichtig ist:

• In einem normalen HTML-Element ist der Titel unbedenklich: <title>{{page::pageTitle}}</title> wird zu <title>Farrokh "Freddie Mercury" Bulsara</title>
• In einem HTML-Attribut hingegen zerstört er das Markup: <img alt="{{page::pageTitle}}"></img> wird zu <img alt="Farrokh "Freddie Mercury" Bulsara"></img>. Richtig wäre jedoch <img alt="Farrokh &amp;quot;Freddie Mercury&amp;quot; Bulsara"></img>.

Andere typische Beispiele sind < und > die in einem HTML-Kontext problematisch sind, aber beispielsweise in JSON keine Bedeutung haben.

Natürlich sind das jetzt ungefährliche Beispiele aber sie zeigen das Grundproblem auf. Dadurch, dass der Kontext nicht bekannt ist, öffnen wir die Büchse der Pandora für eine Vielzahl von potenziellen Angriffsmöglichkeiten.

Wer weitere Informationen zur Problematik haben möchte, kann sich gerne Moritz' Ausführungen durchlesen.

Martin und Moritz haben das halbe Treffen an Verbesserungen an unserem Insert-Tags-Konzept gearbeitet. Twig wird uns hier massiv helfen und es ist deshalb auch klar, dass unsere eigenen PHP-Templates auf längere Sicht der viel mächtigeren Template-Sprache Twig weichen müssen. Template-Sprachen wie Twig haben gegenüber nativem PHP den grossen Vorteil, dass sie in der Regel «geparsed» werden und der Kontext dadurch bekannt wird. Entsprechende Verbesserungen für unsere Twig-Implementierung haben den Weg bereits in den Code für Contao 4.13 gefunden.

Des weiteren wird es möglich sein, ähnlich wie bei HTML-Tags und -Attributen systemweit nur gewisse Insert-Tags zu erlauben. Damit kann auch verhindert werden, dass Redakteur:innen an beliebiger Stelle unerlaubte Daten oder Module (z.B. via {{insert_module::xx}}) ausgeben können.

Nichts was man direkt sehen kann, aber eben auch eine wichtige Investition an Zeit und Hirnschmalz, die Contao für uns alle sicherer machen wird!

Symfony Security

Andy und meine Wenigkeit haben uns mal wieder mit den Backend-Berechtigungen auseinandergesetzt. Immer noch mit dem langfristigen Ziel, diese endlich nicht mehr in onload_callbacks zu haben, sondern als separate, wiederverwendbare Security Voter. Dies ist eine zwingende Voraussetzung in Richtung einer API.

Wir machen hier auf jeden Fall Fortschritte. Fast alle Backend-Berechtigungen werden in Zukunft über das Security-System von Symfony geprüft. Dafür notwendig ist auch ein etwas anders konfigurierter Access Decision Manager, als der, den Symfony standardmässig mitliefert. Der ist neu ebenfalls korrekt für Contao konfiguriert und es gibt auch bereits Ansätze, jegliche DCA-Operations automatisch per Voter zu prüfen. Es ist noch ein weiter Weg dahin, alle checkPermissions-Callbacks loszuwerden, aber wir arbeiten daran. Ob wir das alles noch für die 4.13 LTS schaffen wird sich zeigen.

David hat sich der von Symfony überarbeiteten Security-Komponente angenommen und arbeitete daran, die nötigen Änderungen in Contao vorzubereiten. So wie es im Moment aussieht, werden wir in Contao 4.13 nicht auf das neue Security-System umstellen können, da dies nur mit erheblichen BC-Breaks möglich ist. Entsprechend wird das wohl erst mit Contao 5 und Symfony 6 Einzug in unser geliebtes CMS finden, aber seine Arbeit dürfte die Integration erheblich erleichtern.

Ablösung des Install-Tools

Wie immer beschäftigte uns nicht nur Contao selbst, sondern auch das Ökosystem. Martin und Andy haben ein Konzept für die Konfiguration der Erweiterungen erarbeitet. Stand heute ist es denkbar, dass wir den ConfigTree von Bundles wiederverwenden können. Wir sind uns allerdings noch nicht sicher, wie die Integration im Manager möglichst benutzerfreundlich erfolgen kann. Ausserdem werden wir wohl nicht einfach alle Bundles zur Konfiguration anbieten (wollen), da ein grosser Prozentsatz für die meisten User nicht relevant sein wird.

Andy hat sich zudem mit der Integration von contao:migrate beschäftigt, um Datenbankänderungen direkt im Contao Manager ausführen zu können. Den SQL-Import für Themes wollen wir vorerst ins Contao Backend verschieben.

Nativer rel="canoncial" Support

Eher per Zufall haben wir ein - unserer Meinung nach - ziemlich tolles Konzept für rel="canonical"-Links entwickelt. Dank des neuen Konzepts des ResponseContext von Contao 4.12, haben wir jetzt die Grundlage dafür, globale Arrays wie $GLOBALS['TL_HEAD'] etc. Schritt für Schritt abzulösen.

Mit der Integration habe ich mich beschäftigt und so wird Contao 4.13 über einige Neuerungen verfügen:

• Nativer rel="canonical"-Support wird optional per Root-Seite aktivierbar sein, damit bestehende Seiten unbehelligt bleiben (da ist sie wieder, die Rückwärtskompatibilität).
• Jede Seite wird standardmässig auf sich selbst zeigen, dabei kann konfiguriert werden, welche Query-Parameter behalten werden sollen.
• Entwicklerinnen und Entwickler können die Konfiguration erweitern, indem sie beispielsweise dynamische Parameter selbst hinzufügen.
• Es besteht auch die Möglichkeit, eine beliebige, manuell gewählte URL zu nutzen.
• Unser Crawler folgt in Zukunft auch rel="canonical"-Links.
• Unser Suchindex ignoriert in Zukunft Seiten, die über einen rel="canonical"-Eintrag verfügen, der nicht auf sich selbst zeigt.

Das Maker-Bundle

Jim hatte sich schon beim letzten Entwicklertreffen mit dem Maker-Bundle beschäftigt und es scheint nun endlich Einzug in Contao finden zu können! Eine grossartige Erleichterung für viele Entwickler und Entwicklerinnen. Bitte helft Jim und sorgt dafür, dass es die Sachen macht, die ihr euch wünscht.

Verschiedenes / Bugs

Es gibt natürlich wie immer noch viele weitere, mehr oder weniger kleinere Verbesserungen und komplexere Bugs, an deren Lösung wir gearbeitet haben:

• David arbeitet an einer Möglichkeit, abhängig von der geladenen Root-Seite ein jeweils anderes Frontend-Modul einzubinden. Es soll das Layouting bei mehreren Sprachen vereinfachen und dafür sorgen, dass der {{insert_module::*}} Insert-Tag an Popularität verliert.
• Moritz und Martin haben endlich eine Lösung für die Doctrine server_version gefunden (morgens um 4 Uhr!).
• Andy hat an PHP 8-Attributes als Ersatz für unsere @Hook, @Callback etc. Annotations gearbeitet.
• Fritz und Andy haben eine Lösung erarbeitet, damit auch alte Inhaltselemente, welche noch nicht als neue Fragments gebaut sind, die Caching-Informationen der gesamten Seite beeinflussen können. So wird es in Zukunft möglich sein, dass Contao die Start- und Stopzeit von Elementen erkennt und bei Bedarf die eingestellte Cache-Zeit der Seite automatisch reduziert.
• Fritz hat sich der Problematik angenommen, dass unser Upload-Formularfeld die hochgeladene Datei im Fehlerfall nicht löscht. Das Problem wäre relativ schnell behoben gewesen, aber dann kam wieder die Rückwärtskompatibilität und aus ein, zwei Stunden Aufwand wurden mehr.
• Martin hat uns mit einem neuen Template-Inhaltselement versorgt. Damit wird uns die Möglichkeit geschenkt, einfach ein beliebiges Template an einem beliebigen Ort mit beliebigen Daten auszugeben. Man muss dann nicht mehr ein leeres HTML-Inhaltselement mit eigenem Template anlegen.
• Fritz und Andy arbeiten an einer Lösung, damit Seitentypen ohne eigene Route möglich werden (z. B. für 404 oder 403 Seitentypen).
• Leo hatte wie immer die Ehre, lästige Aufräumarbeiten zu erledigen. So wird es beispielsweise in Zukunft einen HtmlDecoder Service geben anstatt statischer Methoden auf der StringUtil uvm.

Am gesamten Treffen kamen knapp 30 Pull Requests zusammen, wovon solche dabei sind, die aus Änderungen an über 60 Dateien und knapp 4'000 Zeichen bestehen.

That's all Folks!

Ich freue mich darauf, euch hoffentlich bald mal wieder in Echt zu sehen!

– Yanick