Contao-News

Jedes Jahr trifft sich das Contao Core-Entwicklerteam zweimal für einen kurzen Code-Sprint von drei Tagen. Getroffen haben wir uns - wie bereits die letzten beiden Treffen - in Freudenstadt im schönen Schwarzwald. 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.

Ausgangspunkt

Beim letzten Treffen stand Contao 5.3 LTS im Zentrum. Wie immer bei einer neuen LTS-Version, sind die Treffen und die Zeit vor dem Release ziemlich anstrengend. Es gibt immer Dinge, die wir unbedingt noch in die LTS-Version bringen möchten. Dazu gehörten dieses Mal u.a. diverse Stabilitätsverbesserungen, Performance-Verbesserungen aber auch neue Funktionen, die die Sicherheit von Contao noch weiter verbessern, wie etwa das brandneue Content Security Policy-Framework.

Contao 5.3 LTS ist jetzt veröffentlicht, aber damit natürlich nicht vom Tisch. Auch hier wiederholt sich die Geschichte bei jeder LTS-Version: Die Nachfrage ist ungleich grösser als bei anderen Versionen und so kommen auch deutlich mehr Bugreports rein, um die wir uns kümmern müssen. Entsprechend ist dieses erste Treffen nach der Veröffentlichung auch eine gute Gelegenheit, uns dieser Bugfixes anzunehmen.

Sicherheitslücken

Neben regulären Bugfixes erreichten uns in den vergangen zwei Wochen auch zwei Meldungen zu Sicherheitslücken. Daneben haben wir während des Treffens noch deren weitere drei gefunden. Alle fünf Sicherheitslücken waren nicht unbedingt einfach zu beheben und erforderten Absprachen innerhalb des Core-Teams. Auch hier kam natürlich das Entwicklertreffen gerade richtig. Hier geht es zur Ankündigung der Sicherheitsreleases.

Die logische Konsequenz davon: Wir haben dieses Mal deutlich mehr Zeit in Bugfixes bzw. das Beheben von Sicherheitslücken und weniger in Funktionen für zukünftige Versionen investiert, als das bei vergangenen Treffen der Fall war. Meine Wenigkeit, zum Beispiel, war das halbe Treffen mit der Behebung einer Sicherheitslücke beschäftigt.

Aber so ist es nun mal - Sicherheit und Stabilität gehen bei Contao eben vor.

Zukünfigte UX-Verbesserungen

Kommen wir aber nun zu den schöneren Geschichten. Beim letzten Treffen haben wir bereits angefangen, einige UX-Verbesserungen am Backend vorzunehmen. Diesen Weg gehen wir jetzt weiter. Vor Contao 5.3 LTS waren Wrapper-Inhaltselemente der übliche Weg, Inhaltselemente zu verschachteln. Das hat jahrelang funktioniert, aber war UX-technisch offensichtlich nicht die beste Lösung. Dank der neuen verschachtelten Inhaltselemente können wir nun ein Problem ad-acta legen. Mit der neu ermöglichten Verschachtelung haben wir aber die Büchse der Pandora der verschachtelten Navigationsebenen geöffnet. Das Breadcrumb im Backend ist der Aufgabe schlichtweg nicht gewachsen, so dass es für Benutzer:innen quasi unmöglich ist, zu wissen, in welchem Seiten-Kontext oder eben innerhalb welches verschachtelten Inhaltselements sie gerade arbeiten. Martin hat sich dieses Problems angenommen und versucht, die Logik, die in verschiedensten Ecken von Contao angesiedelt war, zu zentralisieren und in einem Service zu bündeln. Das würde uns die Möglichkeit geben, Breadcrumbs konsistenter und zuverlässiger zu generieren und die Benutzer:innen entsprechend besser durch das Backend zu leiten.

Wir hätten im Backend auch gerne etwas mehr App-Feeling. Weniger komplette Seitenreloads, mehr dynamisches Nachladen von Inhalten, mehr Drag n' Drop etc. Als Tool der Wahl dafür haben wir uns schon seit längerem auf Turbo (Hotwire Stack) geeinigt. Allerdings gab es bisher immer noch andere Baustellen, die zuerst fertiggestellt werden müssen. Moritz hat bei diesem Treffen nun endlich ein bisschen Zeit gefunden, eine Grundlage für die globale Integration von Turbo im Contao-Backend zu prototypen. Bei dem verbleibenden Berg an MooTools-Altlasten eine...naja, nennen wir es mal Herausforderung :-)

An dieser Stelle erlaube ich mir mal einen kleinen Aufruf: Wer auch immer sich befähigt dazu fühlt, alte MooTools-Funktionen im Backend durch wiederverwendbare Stimulus-Controller abzulösen (Beispiele im Core gibt es dafür schon einige), sei herzlich dazu aufgerufen, mitzuhelfen!

Migration der verbleibenden Permissions

Andy hat über die letzten Contao-Versionen ca. 80% unserer Berechtigungen auf das neue Berechtigungssystem umgebaut, das wir in Contao 5.0 eingeführt haben. Nach diesem Treffen dürften wir nun bei 90% angekommen sein. Die Migration ist also fast abgeschlossen! 100% sind die Voraussetzung, überhaupt mit dem API-Gedanken spielen zu können - eine API, die an unserem Berechtigungssystem vorbei arbeitet, wäre nicht sonderlich zielführend.

Passkeys / FIDO2

Beim letzten Treffen hatten wir uns bereits mit Passkeys beschäftigt. Fritz hat diesen Faden aufgegriffen und an einem Proof Of Concept gearbeitet. Am Ende des Treffens konnte er uns bereits eine grob lauffähige Variante zeigen, bei der ein Backend-User eigene Passkeys verwalten und sich mit diesen einloggen konnte. Als nächsten Schritt geht es hier sicher darum, das PoC weiter auszufeilen und als eine erste Version für den Core fertig zu machen. Danach wird sicher auch die Integration im Frontend für Frontendmitglieder ein Thema werden.

Twig-Slots

Was das Frontend angeht, steht immer noch die Migration der fe_page.html5 auf ein Twig-Template an. Natürlich nicht einfach nur das Template umschreiben - das ginge ja heute bereits. Hier sprechen wir von einem neuen Konzept der Seitenlayouts und wie Artikel und Module den verschiedenen Sections zugewiesen werden. Moritz hat hier weitere Grundsteine gelegt und das Konzept der Twig-Slots finalisiert. So wird es in Zukunft möglich sein, dass man in Twig-Templates Slots definieren und durch das System dann auslesen kann.

{# @Contao/foo.html.twig #}
<div class="wrapper">
  {# simple usage #}
  {% slot main %}{% endslot %}

  {# usage with placeholders #}
  {% slot left %}
      <aside>{{ slot() }}</aside>
  {% endslot %}
  
  {# using optional fallback values #}
  {% slot footer %}
      <aside>{{ slot() }}</aside>
  {% else %}
      <!-- there is no footer -->
  {% endslot %}
</div>

So können wir dann eben main, left und footer aus dem Template auslesen. Wir hätten also keine willkürlich definierten "Custom Sections" mehr, sondern Artikel und Module könnten nur zu wirklich im Template existierenden "Slots" zugewiesen werden. Eine Fehlerquelle weniger. Cool, oder?

Verschiedenes

Des Weiteren verfolgen wir nach wie vor verschiedene Projekte. Sehr interessiert sind wir am Neos Content Repository, das eine mögliche Teil-Lösung für unsere fehlende, zentrale Datenspeicher-Logik sein könnte. Da gibt es ein bisschen Prototyping von meiner Seite.

Leo möchte gerne die Ladeperformance von grösseren Listen-/Baumansichten verbessern und spielt mit dem Gedanken, wieder auf ein Icon-Set zu wechseln. Ausserdem hat er sehr viel Zeit damit verbracht, Uraltkonzepte wie bspw. das global $objPage bzw. $GLOBALS['objPage'] auf deren moderne Alternative (in diesem Fall den PageFinder-Service) umzubauen.

Dave arbeitet daran, geschützte Seiten endlich auch auf Kommandozeile indexieren zu können und hat diverse Bugs mit der Kompatibilität zu neueren Symfony-Versionen behoben.

Zusammen mit Fritz hat meine Wenigkeit die Überwachung unserer Background-Worker verbessert und Windows-Support eingebaut.

That's all Folks! Vergesst nicht das Contao Camp vom 20. & 21. April in Essen und bleibt gesund!

– Yanick