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 2023

von Yanick Witschi – Aktuelles

Jedes Jahr trifft sich das Contao Core-Entwicklerteam zweimal für einen kurzen Code-Sprint von drei Tagen. Nach drei Treffen in Folge, bei dem immer jeweils ein Core-Entwickler ausgefallen war, konnten wir uns dieses Mal endlich wieder alle sieben gemeinsam treffen. Getroffen haben wir uns - wie bereits im Frühjahr - 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.

Vision und Contao-Backend

Traditionell fängt jedes Treffen am Sonntagabend an und meistens diskutieren wir dabei eher strategische bzw. visionäre Themen und weniger konkrete Problemstellungen und deren Lösungen. Die ausgedehnte Diskussion, die bis tief in die Nacht dauern sollte, endete mit der Erkenntnis, dass uns die DC_Table, realistisch betrachtet, noch über Jahre hinweg begleiten wird. Wer meine Blogposts regelmässig liest, weiss, dass wir gerne darüber diskutieren, wie unsere Wunschlösung für das Backend bzw. die Datenhaltung aussehen würde. API, Event Sourcing, usw.

Da wir alle unentgeltlich an Contao arbeiten, brauchen solch fundamentale Konzeptwechsel eine sehr lange Vorlaufzeit. Aber auch Luftschlösser werden schliesslich nicht an einem Tag gebaut.

Insofern haben wir uns dazu entschieden, über die nächsten Versionen die DC_Table auch wieder vermehrt dahingehend zu überarbeiten, dass sich ihre Wartbarkeit und Verständlichkeit verbessert. Daneben wollen wir auch weitere DX- und UX-Verbesserungen einbauen. Dazu gehören bspw. auf der Entwickler*innen-Ebene Optimierungen wie automatisierte operations und global_operations, die sich abhängig von Permissions automatisiert ein- bzw. ausblenden. Für die User arbeiten wir weiterhin daran, die alte MooTools-Logik Schritt für Schritt auf modernes JavaScript mit Stimulus und Co. umzubauen und dabei hat insbesondere Andy auch bei diesem Treffen wieder diverse kleine Optimierungen vorgenommen. Man achte in den kommenden Versionen bspw. auf schöneres Nachladen von Baumansichten, Elemente auf- und zuklappen uvm.

Passkeys

Der Beginn vom Ende von Passwörtern. So zumindest lesen sich die vielen Ressourcen zum Thema Passkeys, die man im Internet findet. Ich lade euch an dieser Stelle gerne dazu ein, euch mit dieser Materie ein wenig vertraut zu machen. Hinter den Passkeys stehen die illustren Namen der Mitglieder der FIDO-Allianz. In sehr einfachen Worten ausgedrückt sind Passkeys eine alternative Login-Variante, bei der eben kein Passwort mehr verwendet werden muss. Daraus verspricht man sich erhöhte Sicherheit und Usability für die Nutzer*innen des Internets.

Auch wir möchten auf diesen Zug aufspringen und eine Registrierung bzw. ein Login mittels Passkeys in Zukunft erlauben. Alles, was Contao potenziell sicherer macht, hat grundsätzlich sehr guten Chancen bei uns, für den Core berücksichtigt zu werden. Darüber, ob wir das wollen oder nicht, gab es folglich eigentlich keine grosse Debatte. Aber natürlich gaben die technischen Implementierungsdetails einiges zu diskutieren, denn selbst die grossen Player, die Passkeys bereits anbieten, waren sich offenbar nicht einig bei der Frage, ob ein Passkey auch den Benutzernamen und die Zweifaktor-Authentifizierung ersetzt oder nicht. Während bspw. bei GitHub der Passkey alleine zur Anmeldung reicht, verlangt Google weiterhin auch einen Benutzernamen und bei Amazon und Paypal müsst ihr sogar den Benutzernamen und ein One-Time-Passwort angeben. Wir haben uns nach eingehender Recherche dazu entschieden, die GitHub-Implementierung zu verwenden, da die biometrische Entsperrung des Passwort-Managers, in dem der Passkey gespeichert ist, bereits der zweite Faktor ist und das One-Time-Passwort somit ersetzt.

Da die Technologie gerade erst am Anfang steht und wir nur noch bis Ende des Jahres Zeit haben, um neue Funktionen für Contao 5.3 LTS einzubauen, wird sich an den bestehenden Login-Möglichkeiten vermutlich erstmal noch nichts ändern.

Neues Layout-Konzept

Mit jeder neuen Contao-Version wird Twig tiefer und tiefer in den Core eingewoben. Wir kriegen neue Funktionen innerhalb der Templates, weitere Debug-Möglichkeiten und eine immer noch bessere Integration ins Backend. Vielen Dank an dieser Stelle an Moritz für die ganze harte Arbeit!

Nachdem in Contao 5 alle Inhaltselemente auf neue Controller und Twig umgestellt wurden, stellt sich nun die Frage nach der Alternative für unsere fe_page.html5-Templates. Wir möchten ja nicht nur einfach alles 1:1 auf Twig umstellen, sondern diese Gelegenheit - wie bereits bei den Inhaltselementen - auch dazu nutzen, aufzuräumen und den Status Quo zu hinterfragen. Wenn man sich nämlich mal die Optionen im aktuellen Seitenlayout so anschaut, dann gibt es da diverse Einstellungen, die obsolet sind. Ein altes CSS-Framework auf Basis des "Holy Grail"-Konzepts bspw. scheint im Zeitalter von Flexbox und CSS-Grid nicht mehr sonderlich zeitgemäss.

Hier haben wir darüber diskutiert, wie wir Seitenlayouts in Zukunft gerne konfigurieren würden. Ein Ergebnis aus der Diskussion ist, dass die Sections (oder Slots), die man heute im Layout selber definieren und denen man danach Artikel bzw. Frontendmodule zuweisen kann, eigentlich aus dem Template selbst ausgelesen werden sollten. Denn da müssen die ja drin stehen und mit Twig haben wir eben jetzt die Möglichkeit, eigene Tags mit Contao-spezifischer Bedeutung zu erfinden und diese Informationen auch aus dem Template auszulesen. Danach ging die Diskussion weiter in Richtung von erweiterten Seitencontrollern, verbesserter "Content Composition" und ersten Proof-Of-Concepts.

Dass sich primär Moritz in diesem Bereich engagiert, versteht sich fast schon von selbst. Ich bin gespannt, was daraus wird :-)

Verbesserungen an den Background-Workern

In Contao 5.1 haben wir Unterstützung für echte Background-Worker eingeführt. Das eröffnet uns ganz neue Möglichkeiten. In Zukunft wünschen wir uns bspw. dass der Versand von Newslettern im Hintergrund ausgeführt werden kann. Oder dass der Crawler, der u.a. den Suchindex neu aufbaut, das im Hintergrund erledigt. Aber auch noch nicht existierende, neue Funktionen könnten auf den Workern aufbauen. Dazu gehört auch eine Backend-Suche, die, damit sie einigermassen sinnvoll funktionieren könnte, ebenfalls laufend Inhalte im Hintergrund indexieren müsste.

Hier gab es noch diverse Baustellen, die verbessert werden mussten. Dazu gehört unter anderem Logging bei fehlgeschlagenen Messages aber auch sinnvolle Supervision, so dass nicht plötzlich zu viele Worker gestartet werden. Insbesondere beim letztere Teil war uns wichtig, dass wir den noch vor dem Erscheinen der 5.3 LTS erledigen können.

Ausserdem haben wir ein Konzept ausgearbeitet, wie diese Aufgaben in Zukunft ggf. in einem einheitlichen Job-Interface angezeigt und eingesehen werden könnten. Also mit anderen Worten, wir würden den aktuellen Fortschrittsbalken beim Crawler gerne generalisieren und alles, was irgendwie im Hintergrund passiert, so ähnlich darstellen. Nur dass eben mehrere davon gleichzeitig laufen könnten und auch Erweiterungen von einem entsprechenden Framework profitieren können.

Da der ursprüngliche Pull Request für Background-Worker aus meiner Feder stammt, scheint es so, als wäre ich jetzt für diesen Bereich zuständig. Entsprechend hat sich meine Wenigkeit mit diesen Aufgaben befasst.

schema.org für alle Downloads und Media-Elemente

Wenn ich schon bei meinen Aufgaben bin, schiebe ich noch kurz ein, dass ab Contao 5.3 LTS die Inhaltselemente "Download" bzw. "Downloads" und alle Video-Player-Elemente vollautomatisch schema.org-Daten für alle Dateien ausgeben werden. Diese Möglichkeit besteht übrigens für alle Erweiterungen, die in Zukunft auf das in der 4.13 eingeführte und seither ständig verbesserte virtuelle Dateisystem zugreifen. Die korrekten schema.org Daten für eigene Elemente auszugeben, wird in Zukunft eine Sache von ein paar Zeilen Code. Contao macht den Rest für dich.

Symfony Translations

Es ist seit Contao 4 möglich, ganz normal auch Symfony Translations in Erweiterungen zu verwenden. Es war aber bisher immer noch nicht möglich, mit dem Symfony-Translator mitgelieferte Übersetzungen im Contao-Stil (contao/languages) zu überschreiben. Diesem Problem hat sich Fritz angenommen, so dass wir im Idealfall in Zukunft neu alles über den Translator machen können und wieder ein Stück vom Zugriff auf Superglobalen wegkommen.

Content URL Generator

Das Standardkonzept von Symfony-Routing sieht vor, dass man die Routennamen und deren erforderliche Parameter kennt. Stellen wir uns vor, es gäbe eine Route namens blog_post und die würde so aussehen: /blog-posts/{alias}. Dann würde man den URL-Generator von Symfony ungefähr so bedienen: $urlGenerator->generate('blog_post', ['alias' => 'super-alias']). Dabei würde dann eben /blog-posts/super-alias herauskommen.

Contao bzw. ein Content Management System funktioniert aber ein bisschen anders. Routen sind dynamisch und eigentlich wissen wir auch nicht, wie bspw. die URL zu einer Seite aussieht – sie sollte ja im Idealfall vom Editor beeinflusst werden können. Wir wünschen uns entsprechend schon seit geraumer Zeit eine Möglichkeit, eine zentrale Schnittstelle, um eine URL zu einem "Content" generieren zu können. "Content" bedeutet in unserem Fall eben nicht nur eine Seite, sondern eine beliebige Entität. Also die URL zu einer News, einem Kalendereintrag, einem FAQ-Eintrag usw. Ziel soll es also sein, dass ich als Contao-Entwickler, sowas in der Art tun könnte: $contaoContentUrlGenerator->generate($newsModel). Contao wüsste dann selber, was das $newsModel ist und wie die URL zu diesem Model eben aussehen soll.

Andy hat sich mit einem Proof-Of-Concept beschäftigt und weil sich bestimmt immer noch einige Leser*innen nicht vorstellen können, was genau uns das bringen soll, lasse ich euch einfach mal ein Bild von dem Mockup da und ihr könnt eurer Fantasie dann freien Lauf lassen.

Mockup des Backends, das neue Möglichkeiten von URL-Platzhaltern illustriert. Man könnte dann z. B. {year} oder {month} zu der URL einer News hinzufügen.
Mockup des Backends, das neue Möglichkeiten von URL-Platzhaltern illustriert. Man könnte dann z. B. {year} oder {month} zur URL (Seitenalias) einer News hinzufügen.

DNS-Migration

Ein häufig von Entwickler*innen genanntes Problem ist die URL-Einschränkung von Seitenbäumen und der Arbeit auf verschiedenen Testsystemen bzw. lokal, wo überall andere Domains genutzt werden. Während die produktive Domain vielleicht domain.com lautet, so ist es auf einem Testsystem eine dev.domain.com und lokal domain.wip o.ä.

Das bedeutet, jedes Mal, wenn man die Datenbank z. B. vom produktiven System lokal einspielen möchte, um Tests vorzunehmen oder an neuen Funktionen zu arbeiten, muss man in die Seiteneinstellungen und die produktiven Domains in allen Root-Seiten auf die passenden lokalen Domains umschreiben.

Dafür gab es bereits in der Vergangenheit Vorschläge, aber auf diesem Treffen konnten wir uns jetzt auf eine Lösung einigen, an welcher Fritz gearbeitet hat.

Cross-Domain-Login

Dave hat sich mit Cross-Domain-Logins für die Frontend-Vorschau beschäftigt. Also stellt euch vor, ihr habt unterschiedliche Domains für den deutschsprachigen und den französischsprachigen Seitenbaum. Also bspw. contao-zeitung.de und contao-gazette.fr. Nun loggt ihr euch bei contao-zeitung.de/contao ein, um einen neuen Artikel zu veröffentlichen. Die Frontend-Vorschau funktioniert auch super, solange wir über contao-zeitung. de/preview.php/mein-artikel sprechen. Ihr könnt die versteckten Elemente einblenden und so den Artikel in der Vorschau studieren, bevor ihr ihn veröffentlicht. Aber wenn ihr jetzt diesen Artikel übersetzt und auch diesen euch in der Frontend-Vorschau ansehen möchtet, dann wird das nicht möglich sein, ohne dass ihr euch einmal erneut einloggt. Ganz einfach weil die URL dann contao-gazette.fr/preview.php/mon-article lauten würde und Cookies (also euer Backend-Login) aus Sicherheitsgründen immer nur für eine Domain gelten.

Ein Lösungsansatz wäre, beim Klick auf die Frontend-Vorschau einmalig gültige Tokens zu generieren und den Backend-User dann so dynamisch einzuloggen, so dass er oder sie das gar nicht merkt. Das würde die Usability für diesen Workflow erheblich erleichtern.

Verschachtelte Inhaltselemente

Leo und Martin haben ihre Arbeit an den verschachtelten Inhaltselementen vom letzten Entwicklertreffen fortgesetzt. Dazu gibt es nicht viel Neues zu sagen, was eigentlich schade ist, weil dadurch wird der Abschnitt zu diesem Thema in diesem Blogpost so kurz. Aber ihr dürft mir glauben, diese Funktion bedeutet ganz schön viel Arbeit und erfordert viel Hirnschmalz. Das liegt nicht zuletzt daran, dass auch dieses Feature die DC_Table betrifft.

Diverse Verbesserungen und Bugfixes

Die Entwicklertreffen bieten auch immer wieder die Gelegenheit, komplexere Bugs zu besprechen und entsprechende Bugfixes zu finden. Auch dieses Mal waren es wieder zu viele, um sie alle einzeln zu erwähnen. Aber hier ein kleiner Auszug:

  • News, FAQ, Kalendereinträge und Newsletter-Detailansichten werden in Zukunft auch in der sitemap.xml ausgegeben, wenn ein Mitglied eingeloggt ist, was das Indexieren von geschützten Seiten verbessern sollte. Danke Dave!
  • Der Picker funktioniert jetzt auch mit dynamischer ptable korrekt - danke Martin!
  • Eigene Routen können in Zukunft in der Managed Edition einfacher registriert werden - danke Andy!
  • Eine Performance-Verbesserung bei nicht vorhandenen Sprach-Dateien, danke Fritz!
  • Eigene Downloads-Inhaltselemente können in Zukunft dank eines neuen AbstractDownloadContentElementController deutlich einfacher implementiert werden.
  • Ein komplexer Bug mit sich wiederholenden Events wurde endlich gefixt - danke Martin!

Bedanken möchte ich mich auch noch bei Maren, die uns leckeren Kuchen vorbeigebracht hat! Das war sehr aufmerksam und wir schätzen das sehr, vielen lieben Dank, Maren!

Ansonsten möchte ich noch Folgendes loswerden: Bald ist wieder ein Jahr vorbei. Vor uns liegt ein spannendes Jahr. Wahrscheinlich werden viele von euch mit dem Erscheinen der Contao 5.3 LTS ein erstes Mal mit Contao 5 arbeiten. Das Jahresende ist immer eine gute Gelegenheit für ein bisschen Selbstreflexion. Vielleicht auch mal zum Businessmodell der eigenen Firma. Wer diese Entwicklertreffen-Blog-Post-Serie regelmässig gespannt verfolgt und sich im Alltag auf Contao verlässt, um den eigenen Lebensunterhalt zu finanzieren und sich immer noch nicht finanziell an Contao beteiligt, dem oder der möchte ich ans Herz legen, den Budgetplan für 2024 nochmal zu überdenken.

That's all Folks! Geniesst die kommende Adventszeit, schaltet auch mal einen Gang zurück, organisiert noch den ein oder anderen Contao-Stammtisch und drückt eure Liebsten.

– Yanick

Alle News anzeigen

Kommentare

Kommentar von Torsten |

Danke für den ausführlichen Bericht und Eure tolle Arbeit. Contao rockt. 🚀

Kommentar von Marcel |

Vielen Dank für den interessanten Bericht zur aktuellen und zukünftigen Entwicklung von Contao. Ich freue mich auf die neuen LTS und die Projekte die wir alle damit auch in Zukunft sicherlich umsetzen werde!

Kommentar von Hans-Jörg |

Ihr seid großartig, danke!

Kommentar von Dean |

Einfach mal Danke sagen: Danke für Euer Contao-Engagement.

Kommentar von Andreas |

Hört sich wirklich gut an! Vielen Dank euch!

PS: Bequeme Couch habt ihr da 🦥 :D

Kommentar von Frank aka cutbase |

Auch von meiner Seite einen herzlichen Dank für Euer unermüdliches Engagement.

Kommentar von Rory |

Genial! Danke für euren unermüdlichen Einsatz für Contao! Wir freuen uns scho sehr auf die vielen coolen Features, besonders die DNS-Migration und das Cross-Domain-Login, die im Alltag extrem nützlich sein werden.

Ist beim Thema Layout an dem Ihr arbeitet weiterhin ein Ansatz denkbar, um die Konfigurationen z.B. als yml zu speichern und Module z.B. mit Alias anzusprechen, um das uf Code-Ebene versionisierbarer zu machen?

Antwort von Yanick Witschi

Hey Rory, danke für die lieben Worte!

Wir machen bei allen Features ständig den Spagat zwischen den zwei Welten. Einerseits ist es für uns Entwickler*innen wünschenswert, möglichst wenig in der Datenbank und möglichst viel in versionierbaren Dateien zu haben. Andererseits sind wir ein CMS und es muss eben auch für reine Anwender*innen einfach funktionieren. Manchmal ist dieser Spagat nicht ganz einfach aber er ist uns bspw. bei den Bildgrössen ganz gut gelungen, wie ich finde. Zu deiner Frage zu den Frontend-Modulen: Ein Alias ist aktuell nicht geplant (Pull Requests willkommen, Contao ist ein Community-Projekt :-)), aber seit Contao 5.2 kannst du auch Module in dein Template packen, die nicht einmal in der Datenbank stehen ;-)

Einen Kommentar schreiben

Was ist die Summe aus 4 und 7?