Contao-News

Wir informieren Dich hier regelmäßig zu Updates, stellen Best-Practice-Arbeiten vor und berichten über Aktuelles aus dem Contaoversum.

Rückblick auf das zweite Core-Entwicklertreffen 2022

von Yanick Witschi – Aktuelles

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 ich letztes Mal leider nicht vor Ort sein konnte. Leider hat sich das Szenario dieses Jahr ähnlich wiederholt, nur hat es dieses Mal Martin getroffen und wir haben uns deshalb nur zu sechst im wunderschönen Schwarzwald getroffen. Was? Colmar liegt doch nicht im Schwarzwald und ein Core-Entwickler weniger ergibt doch sieben und nicht sechs?

Sehr aufmerksam! Ja, Colmar haben wir den Rücken gekehrt. Die Stadt ist definitiv einen Besuch wert und sollte bei der Erkundung des Elsass sicher nicht in der Reiseplanung fehlen! Aber die Räumlichkeiten da waren einfach insgesamt etwas ungeeignet für uns. Also haben wir uns dazu entschieden, etwas Neues auszuprobieren und haben nach der Schweiz und Frankreich wieder etwas in Deutschland gefunden. In eben jenem Schwarzwald, den ich eingangs erwähnt hatte. Kleiner Tipp am Rande, für diejenigen, die bereits den nächsten Urlaub planen: Deutschland hat unglaublich viel zu bieten, man muss nur hinsehen – bitte sehr:

Und dann war da noch die Diskrepanz bei der Anzahl an Core-Entwicklern. Wer die Contao-News regelmässig liest, kennt die Antwort natürlich bereits. Für alle anderen: Eine zusätzliche Person weniger waren wir, nachdem Jim das Core-Team auf eigenen Wunsch hin verlassen hat. An dieser Stelle würde ich gerne auch nochmal hervorheben, dass Jim Contao über Jahre mitgeprägt und verbessert hat. Lasst ihm doch ein Danke auf Twitter da, denn ohne ihn wäre das Projekt Contao heute sicher auch nicht da, wo es jetzt ist. Vielen herzlichen Dank, auch von mir, lieber Jim. Du hast uns gefehlt und wirst uns weiterhin fehlen. <3

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.

Ausgangslage

Das letzte Entwicklertreffen war geprägt von Contao 5. Geprägt von hunderten von Pull Requests, die einen der oft erwähnten „BC-Layer“ nach dem anderen aus dem Core entfernt haben. Oder anders ausgedrückt bestand das letzte Treffen vor allem aus einer Hauptaufgabe für uns alle: Aus unglaublich viel Fleissarbeit. Dieses Mal gestaltete sich die Ausgangslage etwas anders, da Contao 5 mittlerweile da ist und äusserst stabil läuft. Wir konnten also die Zeit wieder nutzen, um die Dinge zu tun, die man zuhause oder im Büro alleine nicht wirklich gut tun kann: Diskutieren, experimentieren und konzeptionieren.

Wie immer ist vieles nicht spruchreif. Wir diskutieren auch über langfristige Visionen, damit sich alle einig sind, wohin der Weg führen soll. Aber schlussendlich können wir nicht alles an einem Treffen von drei Tagen umbauen, sondern wir essen den Elefanten eben wie man einen Elefanten isst: Stück für Stück. Das langfristige Ziel einer allgemeinen API ist immer ein zentraler Diskussionspunkt. Wir haben zwar seit Contao 5 eine neue Möglichkeit, Berechtigungen unabhängig vom Contao-Backend und somit auch in einer zukünftigen API zu prüfen, aber es fehlen noch weitere Bausteine. Das grösste Problem ist und bleibt der fehlende zentrale Speicher. Datensätze werden im Backend über die DC_-Treiber gespeichert, vor allem im Frontend verwenden wir Models und dann gibt es auch noch jede Menge Stellen, an denen direkt in die Datenbank geschrieben wird. An manchen Stellen werden Hooks aufgerufen, an anderen wiederum nicht etc. Diese Inkonsistenzen erschweren die Umsetzung eines Projekts wie das einer zentralen API erheblich und wir werden daher über kurz oder lang die Art und Weise, wie wir Daten speichern, überdenken müssen. Hier haben wir die Verwendung von Doctrine ORM in Frage gestellt. Doctrine Entities sind nicht erweiterbar und für ein Content Management System wie Contao, das von eben dieser Erweiterbarkeit lebt, ggf. nicht der richtige Ansatz. Womöglich haben wir hier aber einen neuen Ansatz auf Basis von CQRS gefunden. Wir werden sehen, wo uns diese Diskussionen noch hinführen werden.

Nach jedem Entwicklertreffen gibt es zwar meistens eine Menge kleinerer Pull Requests, die mehr oder weniger bereit für einen Merge sind. Aber gerade die grösseren Baustellen können in den drei Tagen natürlich nicht fertiggestellt werden. Vielmehr ist das Entwicklertreffen eine Art Kick-Off-Veranstaltung für Neues (Proof Of Concepts) das dann über die kommenden Monate in der Freizeit aller Core-Team-Mitglieder fertiggestellt wird und schliesslich den Weg in Contao findet.

Schauen wir uns also an, an was für Proof Of Concepts denn dieses Mal so gearbeitet wurde.

Security

Es ist ja schon zu einem Running Gag geworden, dass sich Dave auf jedem Entwicklertreffen mit Symfony Security beschäftigt. Aber auch dieses Mal war das nicht anders. Symfony hat mit dem Release von Version 5.1 (experimental) auf eine komplett überarbeitete Version von Symfony Security umgestellt. Die Umstellung auf diese deutlich einfacher zu verstehende Variante hat bei uns in Contao 5.0 stattgefunden. Wir können also jetzt von den Vereinfachungen profitieren und neue Features nutzen. Dave hat hierbei an einem Authenticator für temporäre JSON Web Tokens gearbeitet. Diese bilden die Basis dafür, in Zukunft contao:crawl auch für geschützte Seiten nutzen zu können. Ausserdem wird Contao 5.1 höchstwahrscheinlich auch mit zusätzlichem Rate Limiter-Schutz versehen, der im Vergleich zur aktuellen Lösung auch für nicht-existierende Benutzer-Accounts funktioniert. So werden Password Spraying-Attacken in Zukunft noch besser verhindert werden.

Aber nicht nur Dave hat sich im Bereich von Security bewegt. Auch Fritz hat an seinem Konzept für die Integration von OAuth-Support – beispielsweise einem Facebook-Login im Frontend – im Contao-Core gearbeitet und uns ein tolles POC präsentiert. Ich denke das könnte durchaus was werden - aufregende Zeiten!

Übersetzungen

Wenn wir schon bei Fritz sind: Er hat sich auch mit der Möglichkeit einer temporären Sprachumschaltung in unserem Translator beschäftigt. Ein Anwendungsbeispiel wäre etwa, eine englischsprachige E-Mail aus dem Contao Backend, das auf Deutsch eingestellt ist, zu versenden. Aufgrund von unseren $GLOBALS['TL_LANG']-Verwendungen ist das aber leider auch nicht ganz einfach. Also ein Tipp an die Entwicklerinnen an dieser Stelle: Nutzt für den Zugriff auf Sprachdateien in „contao/languages“ einfach immer den Translator wie in der Dokumentation aufgezeigt. Und für eigene, neuere Bundles empfiehlt es sich ohnehin, komplett auf Symfony Translations zu setzen.

JavaScript

Auch an der JavaScript-Front gibt es einiges zu berichten. So ist Andy immer noch auf der Suche nach der besten Lösung für JavaScript im Contao-Backend, das auch in Contao 5 leider immer noch aus relativ viel veraltetem MooTools-Code besteht. Einfach weil es schlichtweg so viel Code ist, dass es zeitlich bis Contao 5 nicht gereicht hat, um es komplett auszubauen. Er hat an einem POC für die Integration von Stimulus gearbeitet, das insbesondere die Selektion der betroffenen DOM-Elemente und somit auch die Migration weg von MooTools deutlich erleichtern sollte. Zusammen mit Leo haben die beiden sich auch um die Integration einer neuen Build-Chain für das Core-Bundle gekümmert.

Virtual Filesystem (VFS)

Moritz ist unser „Mister Twig“. Aber er ist nicht nur für Twig verantwortlich, sondern auch für das virtuelle Filesystem, das wir in Contao 4.13 eingeführt haben. Da meine Wenigkeit am Design dieser Komponente mitgewirkt hat, haben wir beide uns auch über die Zukunft unterhalten. Dabei sind Moritz noch ein paar Unstimmigkeiten aufgefallen, die er kurzerhand behoben hat. Ausserdem haben wir im Plenum diskutiert, inwiefern es sich lohnt, die bestehende Dateiverwaltung zu 100% auf unser neues VFS umzubauen. Wie immer stellt sich nämlich wieder die Frage der Rückwärtskompatibilität bzw. der „BC Layer“. Jetzt ist Contao 5.0 ja stabil und das heisst, für die gesamte 5er-Reihe dürfen wir wieder keine Breaks mehr einführen. Also was kann man noch machen? Genau, sich eine komplett neue Dateiverwaltung ausdenken, die parallel zur jetzigen funktionieren würde. Natürlich auch wieder eine Herkules-Aufgabe. Moritz hat auf jeden Fall mal seine Fühler ausgestreckt und sich verschiedene, bereits existierende Lösungen und deren Integrationsmöglichkeit in Contao angeschaut.

Favoriten

Nachdem Contao 5.0 mehrheitlich ein „Aufräumprojekt“ war, haben wir an diesem Treffen wieder über die Einführung neuer User-Features diskutiert. Natürlich schauen wir dabei auch immer etwas auf die Extensions, die häufig installiert werden. Diese sind ein guter Indikator dafür, was gegebenenfalls im Core von Contao fehlt. Allerdings ist eine populäre Extension alleine noch lange keinen Grund dafür, die Funktionalität in den Core zu übernehmen. Schliesslich gibt es ja eine tolle Extension dafür. Aber es gibt auch andere Fälle, wo die Extension ggf. sehr alt ist oder der Use Case sich generalisieren liesse. So zum Beispiel bei "easy_themes". Tatsächlich handelt es sich dabei um eine der ältesten meiner Extensions. Ich meine ich hätte sie so 2009/2010 in einer ersten Version veröffentlicht, wahrscheinlich aufgrund von Diskussionen auf einer Contao-Veranstaltung. Dass es die Extension 2022 immer noch gibt und diverse Codezeilen von 2010 in Contao 4.13 immer noch funktionieren, zeigt auch, wie gut die BC-Layer von Contao über all die Jahre funktioniert haben. Für Contao 5 wird es höchstwahrscheinlich kein easy_themes mehr geben, weil ich selber die Extension kaum brauche bzw. der Use Case von „mit weniger Klicks ans Ziel kommen“ eben generalisiert werden könnte und es keinen Grund gibt, dieses Problem nur für Themes zu lösen. Folglich haben wir in der grossen Runde diskutiert, wie wir das Problem angehen könnten. Dabei haben wir ein Konzept erarbeitet, das sowohl die Verwaltung von persönlichen Favoriten als auch ein automatisiertes drittes Level im Backend ermöglichen würde. Die Federführung hat hier Leo übernommen und ich bin gespannt auf den ersten Vorschlag. Das Konzept ist übrigens auf GitHub grob umrissen und die Diskussion ist offen für alle.

Rewrites

Eine andere, sehr populäre Extension ist "URL Rewrite". Dass auch die von uns (terminal42 gmbh) stammt, ist übrigens Zufall. Mit ihr lassen sich beliebige URLs auf andere Seiten weiterleiten oder auch "410 Gone"-Antworten generieren, was gerade im SEO-Bereich eine oft nachgefragte Funktion ist. Im Core von Contao hätten wir gerne die Unterstützung von automatischen Umleitungen oder "410 Gone"-Seiten, wenn eine Anwenderin das Seitenalias einer Seite ändert oder diese löscht. Da Contao aber nicht nur aus Seiten, sondern auch News, Kalendereinträgen etc. besteht, muss man Umleitungen oder eben „Rewrites“ auch ausserhalb vom Seitenbaum pflegen können. Und wenn ich ausserhalb vom Seitenbaum sage, dann meine ich damit dennoch irgendwie bezogen auf die Root-Seite. Also dann eben doch nicht ganz so wie es die Erweiterung im Moment macht, sondern im Idealfall eben noch ein bisschen schlauer und mit besserer UX. Diese Initiative leitet Andy und auch hier ist Input herzlich willkommen.

Background Worker

Eines meiner persönlichen, längerfristigen Ziele wäre eine Suchfunktion im Backend. Wir haben bereits eine Suche im Frontend, die über die Jahre immer besser geworden ist. Nur leider lässt sie sich nicht für beliebige Indizes nutzen. Oder nicht-technisch ausgedrückt: Wir können im Moment nicht dieselbe Logik für Backend und Frontend verwenden, da wir sonst die Frontend-Suchresultate im Backend hätten und umgekehrt. Ausserdem gäbe es noch diverse Ansätze, unsere Suche noch viel, viel besser zu machen (Stichworte: Stemming, Normalisierung etc.). Deswegen möchte ich gerne an einer wiederverwendbaren Suchkomponente arbeiten. Martin hat hier ebenfalls Interesse angemeldet und wenn jemand das hier liest und sich denkt „Oh cool!“ und daran mitarbeiten oder sogar mitfinanzieren und somit den Prozess beschleunigen (immer möglich, bei allem was überall in diesem Blogpost steht!) möchte, dann meldet euch gerne bei den jeweiligen Leuten. Ihr findet uns alle bei Slack.

Da Martin leider nicht vor Ort war, konnte ich noch nicht an der Suchkomponente selbst arbeiten. Allerdings wissen wir bereits heute, dass - sollten wir die Suche weiter verbessern können - die Indexierung der Daten ggf. mehr Zeit in Anspruch nehmen wird, als sie das heute tut. Eine noch bessere Suche bedeutet in der Regel noch mehr Analyse der Daten während der Indexierung, so dass sie danach effizient durchsucht werden können. Im Moment geschieht das standardmässig bei jedem Seitenaufruf (wenn der Cache deaktiviert ist), was den Webserver belastet und im schlimmsten Fall sogar dafür sorgt, dass die Antwortzeiten bei Contao langsamer werden. Schön wäre es, wenn die Indexierung im Hintergrund geschehen würde, was auch für viele andere Aufgaben gilt. Hier ein paar Beispiele:

  • E-Mails versenden
  • Viele Dateien komprimieren
  • Reports generieren
  • Langsame APIs abfragen

Ich habe mich damit beschäftigt, Contao mit einem Background Worker auf Basis von Symfony Messenger auszustatten, welcher automatisch benutzt wird, wenn ein echter CLI-Cronjob für Contao eingerichtet wurde (ohnehin immer empfohlen, hier geht es zur Dokumentation). Das würde den Entwicklern ein neues, sehr mächtiges Werkzeug an die Hand geben und die Performance von Contao unter Umständen weiter verbessern. Auch hier darf gerne auf GitHub mitgeholfen werden.

Vermischtes

Ansonsten gibt es wie immer sehr viele Dinge, über die ich nicht sonderlich viel erzählen kann, die aber natürlich auch wichtig sind und z.T. viel Arbeit bedeuten. Leo hat beispielsweise dutzende Tickets von unserem alten Contao 3 GitHub Repository aufgeräumt und einige davon, die noch immer relevant sind, ins aktuelle Projekt überführt. Moritz hat das Download-Element in Contao 5 mit X-Sendfile-Support ausgestattet und dank Andy wird jede Anwenderin in Contao 5.1 selbst entscheiden können, ob Inhaltselemente im Backend standardmässig auf- oder zugeklappt sind. Und ich, naja, hab wie immer noch ein paar zusätzliche Stunden damit verbracht, diese ~2200 Wörter hier zu schreiben und sie ins Englische zu übersetzen.

That's almost all Folks!

Einen kleinen Spoiler hab ich noch für euch: Ich freue mich darauf, euch nächstes Jahr mal wieder in Echt auf einer Contao Konferenz zu sehen!

Yanick

Alle News anzeigen

Kommentare

Kommentar von Bjarke |

Herzlichen Dank für diesen vorzüglichen Rückblick und eurem unermüdlichen Einsatz als Core-Entwickler für Contao. Alles Gute und bis bald in Echt.

Kommentar von Detlef |

Hi Yanick,
es ist mir immer eine Freude deine informativen und sympathisch geschriebenen Rückblicke zu lesen, danke dafür!

Kommentar von Stefan SL |

Danke für deine Arbeit, Yanick.

Kommentar von Marcus Lelle |

Es bleibt spannend. Tolle Ideen und Weichenstellungen für die Zukunft.
Und wie immer ein toll geschriebener Bericht.
Danke Yanick.

Kommentar von Franko |

Vielen Dank für die detaillierte Übersicht und den Arbeitsaufwand.
Drüber hinaus: Das Foto ist wunderbar.

Kommentar von Frank |

WOW 🤩 Vielen Dank für das ausführliche Update und vor allem für euren Einsatz für Contao! 💪🏻

Kommentar von Stefan D. |

Wie immer eine wirklich Tolle Arbeit vom Contao Core Team. Bezüglich Contao Kompatibilität mit BC-Layern frage ich mich, ob für manche oder auch alle BC-Layer nicht die Versionsnummer 4.x, 5.x usw. genommen werden sollte sondern immer LTS Versionen ausschlaggebend sind, da LTS Version sowieso mehre Jahre Unterstützt werden. D.h. BC-Layer sind Stabil bzw. Garantiert für jeweils eine LTS Version ggf. auch zwei LTS Versionen.

Antwort von Yanick Witschi

Hi Stefan,

Wir sorgen bereits dafür, dass die letzte Version vor der neuen Major-Version eine LTS ist. Also die 4.13 ist die letzte der 4er-Reihe und eine LTS-Version. Welche Versionsnummer wir verwenden ist durch Semantic Versioning vorgegeben und unabhängig von LTS-Versionen. Wir könnten jetzt nicht bspw. eine 5.1 LTS releasen und da BC-Layer entfernen. Per Definition müsste das dann Version 6.0 sein.

Einen Kommentar schreiben

Bitte addieren Sie 1 und 6.