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 2019

von

Jedes Jahr trifft sich das Contao Core-Entwicklerteam zwei Mal für einen kurzen Code-Sprint von drei Tagen. Da im Moment vier Entwickler aus der Schweiz kommen, findet das Treffen jeweils ein bisschen ausserhalb von Zürich statt. Die Treffen werden von der Contao Association getragen und sind für uns sehr wichtig. Hier kannst du Mitglied werden und uns somit unterstützen.

Ich habe mir vorgenommen, jeweils nach einem solchen Treffen die wichtigsten Informationen zusammenzutragen und so mit der gesamten Community zu teilen. Dieses Mal haben uns folgende Themen beschäftigt:

Contao 4.9 LTS und Symfony 4.4 LTS

Die nächste Contao-Version wird Contao 4.9, unsere nächste LTS-Version. Stabilität hat deshalb oberste Priorität und bei allen Entscheidungen, die wir die vergangenen Tage getroffen haben, haben wir versucht, sie im Sinne der nächsten LTS-Version zu treffen.

Eine Änderung wird auf jeden Fall die Erhöhung der eingesetzten Minimalversionen der Symfony-Komponenten auf Version 4.4. Dies wird die kommende LTS-Version von Symfony werden und war auch der Grund für die Anpassung unseres Release-Zyklus.

An den Minimalanforderungen an die eingesetzte PHP-Version werden wir nach intensiven Diskussionen voraussichtlich keine Änderungen vornehmen. Eine Erhöhung auf PHP 7.4 und ggf. Umstellung auf «typed properties» könnte dann mit Contao 4.10 ein Thema werden.

Ökosystem

Beim Ökosystem gibt es dieses Mal relativ wenig zu berichten. Der Contao Manager und die Cloud laufen sehr stabil und contao.org hat ein Makeover der Startseite bekommen.

Die zwei grössten Baustellen beim Contao Manager sind die Installation von privaten Paketen und die Konfiguration von Extensions via UI und somit auch der Ersatz für das separate Installtool. Private Pakete für den Manager dürften zur Contao-Konferenz eine Tatsache werden und alle weiteren Optimierungen haben wir erstmal zurückgestellt. Dies aufgrund der kommenden LTS-Version und dem Fokus für dieses Treffen auf Contao als Software.

Zwei nennenswerte Ausnahmen sind die Entwicklerdokumentation und das «Maker Bundle». An der Dokumentation wurde auch bei diesem Treffen fleissig weitergearbeitet. Vor allem Fritz hat hier viel Zeit investiert. Jim's neues Baby ist das kommende «Maker Bundle». Analog der Version von Symfony wird es die Erstellung von Frontend-Modulen, Inhaltselementen, DCA's etc. erleichtern.

Die Dokumentation soll zur Contao-Konferenz veröffentlicht und von da an hoffentlich stetig verbessert und erweitert werden.

Webpack- bzw. Symfony Encore-Integration

Seit Contao 4.5 verfügen wir über das {{asset::*}} Insert-Tag, das es einem erlaubt, dynamisch den jeweiligen Pfad zu einem Asset via manifest.json auszugeben. Dadurch ist es sehr einfach möglich, sich ändernde Pfade (mit Versionierung/Hashing für Cache-Busting) zu generieren und im Seitenlayout einzubinden.

Wir haben uns darüber unterhalten, ob wir eine stärkere Integration vornehmen möchten, welche die Auswahl per Checkboxwizard ermöglicht. Auch interessant wären ggf. die Symfony Encore spezifischen Entrypoints, welche jeweils mehrere Assets gruppieren können.

Nach längerer Diskussion sind wir zum Schluss gekommen, dass eine tiefergehende Integration im Moment nicht wirklich sinnvoll erscheint. Dies insbesondere deshalb, weil die Entrypoints von Symfony Encore für uns nicht wirklich praktikabel sind, da wir nicht im Seitenlayout entscheiden möchten, was geladen werden soll, sondern die jeweiligen Elemente oder Module dies tun sollten. Ansonsten bräuchten wir eine Vielzahl an Seitenlayouts, was wiederum nicht sonderlich praktikabel erscheint. Es gibt ausserdem bereits einige Drittanbieter-Bundles, welche die Integration von Webpack ermöglichen.

Das Thema ist sicher nicht definitiv vom Tisch, aber es gab schlussendlich weit wichtigere Themen, denen wir uns widmen wollten.

Migrations-Framework

Wichtigere Themen wie z.B. ein Migrations-Framework! Ich kann mich persönlich gar nicht mehr daran erinnern, wann das Konzept der runonce.php eingeführt wurde. Es fühlt sich auf jeden Fall so an, als hätte es schon immer existiert. Eine Datei die einfach im Installtool inkludiert, somit ausgeführt und danach gelöscht wird. Die denkbar einfachste Möglichkeit, Migrationen in eigenen Erweiterungen anzubieten. Aber natürlich bringt sie auch etliche Nachteile mit sich:

  • Eine Datei nach der Ausführung löschen, damit sie nicht erneut ausgeführt wird, ist nicht wirklich «state of the art».
  • Fehlermeldungen werden einfach ignoriert.
  • Sie können nicht auf der Kommandozeile ausgeführt werden.
  • Man kann nicht einsehen, welche Migrationen ausgeführt werden, bevor man sie effektiv ausführt, geschweige denn wissen, ob überhaupt was ausgeführt wurde.
  • uvm.

Der Contao Core selbst hingegen, nutzt eigene Migrationsklassen für seine Migrationen und auch andere Erweiterungen haben eigene Interfaces erfunden. Für die 4.9 LTS wurde es daher höchste Zeit, dass wir uns hinsetzen und an einer Lösung für die Allgemeinheit arbeiten.

Martin hat sich der Aufgabe angenommen und so kommt es, dass in Contao 4.9 mit grosser Wahrscheinlichkeit Migrationen in allen Extensions (also auch im Core selbst) bequem als Service getaggt werden können und dann entweder per Installtool oder per Kommandozeile ausgeführt werden können. Dadurch können wir für eine einheitliche Ausführung aller Migrationen sowohl im Installtool als auch auf der Kommandozeile sorgen.

Wir haben lange über die Anforderungen diskutiert und sind überzeugt, eine gute Lösung für alle anbieten zu können, aber wenn ihr gerne mitdiskutieren wollt, dann könnt ihr das natürlich sehr gerne im entsprechenden Pull Request tun.

Cronjob-Framework

Im Hinblick auf unsere nächste LTS-Version würden wir gerne weitere Dinge vereinheitlichen. Dazu gehört die Art und Weise wie man in Contao Cronjobs sowohl ausführt als auch als Entwickler registrieren kann. Insbesondere hätten wir gerne die Möglichkeit, den Poor Man's Cron zu deaktivieren und durch einen echten Cron Job zu ersetzen.

Weiter sollen Entwickler die Möglichkeit haben, die gewünschten Jobs wiederum per Tag am Container zu registrieren und unterscheiden zu können, ob sie gewisse Aufgaben nur bei einem echten Cronjob ausführen möchten oder nicht. Dadurch könnten leichte Aufgaben weiterhin im Poor Man's Cron ausgeführt werden, aber Extensions könnten auch aufwändigere Aufgaben ausführen lassen (z.B. den Suchindex täglich neu aufbauen), wenn eben ein echter Cronjob eingerichtet wurde.

Fritz hat an einer Implementierung gearbeitet und wer hier an der Diskussion teilnehmen möchte, macht das gerne bei Pull Request #708.

Erweiterung der 2-Faktor-Authentifizierung

Dave hat sich erneut mit der 2-Faktor-Authentifizierung beschäftigt. Nachdem Contao 4.8 neu nun auch 2FA für Frontend-Mitglieder anbietet, bleibt nunmehr die Integration von «Trusted Devices» und «Recovery Codes». Ein «Trusted Device» braucht keine erneute Eingabe des zweiten Faktors und die «Recovery Codes» erlauben es einem, sich einzuloggen, auch wenn der zweite Faktor verloren ging.

Diese zwei Features komplettieren unseren langen Weg hin zu vollständiger Zweifaktor-Authentifizierung für die nächste LTS!

Routing

Andy hat seine Arbeit am Contao-Routing weitergeführt und «Folder URL's» sind neu keine Systemeinstellung mehr, sondern können pro Root-Seite und somit innerhalb des Systems unterschiedlich genutzt werden.

Noch offen sind das «URL-Suffix» und die Einstellung «Sprache zur URL hinzufügen». Es wird sich noch zeigen, ob diese Einstellungen ebenfalls pro Root-Seite definiert werden können oder ob es technisch oder aus Rückwärtskompatibilitätsgründen nicht möglich ist.

robots.txt und favicon.ico in der Root-Seite

Meine Wenigkeit hat an der dynamischen Ausgabe von Favicons und der «robots.txt» gearbeitet. Neu kann pro Root-Seite ein Favicon gewählt werden und der Inhalt der «robots.txt» kann ebenfalls in der Root-Seite gepflegt werden. Dadurch können bei Multidomain-Installationen unterschiedliche Favicons ausgewählt bzw. «robots.txt» Inhalte gepflegt werden. Zusätzlich gibt es für die «robots.txt» ein Event, mit dem jeder Entwickler den Inhalt dynamisch verändern kann.

Der Core selbst nutzt das nun, um automatisch alle Sitemaps aller Root-Seiten auszugeben, damit zukünftig das manuelle Registrieren der Sitemaps bei den Suchmaschinen entfällt.

Berechtigungen für Inhaltselemente

Leo hat an der Übernahme der beliebten Erweiterung «ce_access» in den Core gearbeitet, so dass ab Contao 4.9 nur gewisse Inhaltselemente für gewisse Benutzergruppen oder Benutzer freigegeben werden können.

Crawler/Suchindexer

Mein Grossprojekt für Contao 4.9 wird der Umbau des Suchindexers. Zurzeit werden Seiten jeweils beim Seitenaufruf indexiert. Wenn der Suchindex im Backend neu aufgebaut wird, so sucht sich Contao eine Liste aller «durchsuchbaren Seiten» via des Hooks getSearchablePages und ruft diese einfach auf, womit diese Seiten wiederum indexiert werden.

Dieses Vorgehen hat mehrere Nachteile:

  • Der Suchindex kann nicht per Kommandozeile neu aufgebaut werden (per Cronjob z.B.).
  • URLs die im Hook vergessen gehen, werden nicht gefunden und somit nicht indexiert.
  • Schlägt bei grossen Seiten ggf. fehl, weil die Anzahl der Links einfach zu gross ist.
  • Teile der Webseite (Stichwort: ESI) werden ggf. ignoriert.

Vor einiger Zeit habe ich deshalb angefangen, eine Crawler-Bibliothek namens «Escargot» zu schreiben, welche Webseiten mit Hilfe neuester Symfony Komponenten crawlt. Das Ziel ist es, Contao-Installationen via echten Crawler im Frontend zu durchsuchen und zu indexieren. Dies dürfte für deutlich bessere Resultate sorgen.

Ausserdem plane ich eine kleine Abstraktion des Suchindexers so dass Entwickler beliebige Indexer anbinden können um bspw. die Daten in ElasticSearch o.ä. zu indexieren. Der Crawler selbst ist aber nicht limitiert auf das Indexieren von Suchresultaten. Weitere Integrationen wie bspw. einen «Link-Checker» für kaputte Links wären denkbar.

Universal Picker

Andy hat versucht, allen Entwicklern einen grossen Gefallen zu tun und ein universal einsetzbares Picker-Widget zu bauen. Den Picker kennt man im Moment vor allem vom Dateiwähler oder vom News-Beitrag-Wähler, aber wenn das richtige Widget zusammen mit den richtigen Picker-Providern kombiniert wird, kann man die Benutzer jegliche Datensätze im Backend picken lassen.

Seine Implementierung ermöglicht die einfache Nutzung neuer Picker für Entwickler und fügt auch Unterstützung für die Auswahl jeglicher Inhaltselemente und Artikel hinzu. Das erleichtert bspw. die Auswahl beim Alias-Inhaltselement (das Inhaltselement das den Inhalt eines anderen Inhaltselements ausgeben kann) erheblich.

Lazy Loading für Bilder

Martin hat Support für das neue loading="lazy" Attribut eingebaut. Unterstützt wird das zum aktuellen Zeitpunkt nur von Chrome, aber wir werden die Entwicklung beobachten und die Implementierung ggf. anpassen, so dass ihr davon ausgehen könnt, dass Lazy Loading für Bilder in Zukunft nur noch einen Klick entfernt ist.

Bugfixes

Nebst den genannten neuen Features haben wir wie bei jedem Treffen auch einige komplexere Bugs behoben. Natürlich auch mal wieder ein paar anspruchsvollere Caching-Themen, bei denen einfach schnell einmal zwei, drei Stunden ins Land gehen.

Scheitern gehört (nicht immer) dazu

Im letzten Blogbeitrag hatte ich erwähnt, dass ich jeweils erwähnen möchte, an was wir uns die Zähne ausgebissen haben, aber erfreulicherweise fällt mir für dieses Treffen kein Thema ein, an dem wir uns versucht hätten und gescheitert wären :-)

That's it, folks! :-)

Auch über den Ausgang dieses Entwicklertreffen bin ich wiederum sehr glücklich! Wir haben erneut sehr viel geschafft und meiner Meinung nach den richtigen Aufgaben die richtige Priorität zugewiesen.

Es ist wichtig, dass wir den Entwicklern für die nächste LTS gute Tools an die Hand geben können und das meine ich, wird uns gelingen. Aber auch für die Anwender sind bereits heute wieder etliche Verbesserungen in Sicht!

Contao 4.9 LTS wird die beste Contao-Version die es je gegeben hat und darauf wollen wir mit euch auf der Contao Konferenz 2019 am 10. und 11. Oktober anstossen!

Das nächste Entwicklertreffen findet voraussichtlich im Februar oder Anfang März 2020 statt.

– Yanick

Zurück zur News-Übersicht.

Kommentare

Kommentar von Christian |

Vielen Dank lieber Yanick für deinen ausführlichen Bericht.

Die neuen Funktionen und Ideen beweisen einmal mehr, dass Contao nach wie vor ein sehr modernes und technisch aktuelles CMS ist.

Es wäre schon, wenn solche Entwicklertreffen in Zukunft alle 3 Monate stattfinden könnten. Denn der Output ist einfach gigantisch.

Antwort von Yanick Witschi

Danke, Christian! Die Treffen fungieren meistens als eine Art Kickoff für neue Features. Die Arbeit wird dann über die nachfolgenden Monate weitergeführt. Von daher bezweifle ich, dass eine höhere Frequenz viel bewirken würde, zumal unsere Arbeit ja unentgeltlich ist und die zeitliche Belastung bereits jetzt sehr hoch ist. Ich kann nicht für das gesamte Team sprechen, aber in meinem Fall müsste dann definitiv auch finanziell eine Lösung gesucht werden, ansonsten ist es einfach nicht tragbar. Und so gerne ich einen festen Prozentsatz meiner Arbeitszeit an Contao arbeiten würde, so denke ich, sind wir davon noch ein gutes Stück entfernt :) Aber natürlich gibt es immer die Möglichkeit uns über unsere jeweiligen Firmen für die Arbeit an Core-Features zu beauftragen, was in letzter Zeit glücklicherweise auch immer mal wieder passiert (2FA für‘s FE, WEBP-Support, Suchindex-Optimierungen...).

Kommentar von Chris |

Danke, einfach nur danke! :)

Kommentar von Stefan D. |

Wie immer tolle Arbeit vom Contao Team. Die Neuerungen hören sich sehr gut an.
Eine kleine Bitte habe ich noch: Bitte die Cookie Behandlung bei Contao an das neue EU-Urteil anpassen. Soweit ich dieses verstehe, darf ohne Zustimmung überhaupt kein Cookie mehr gespeichert werden auch nicht welche, die nach verlassen der Webseite gelöscht werden.

Antwort von Yanick Witschi

Contao 4.8 setzt im Kern maximal zwei Cookies. Einmal das Session-Cookie und einmal ein Cookie zum Schutz vor CSRF-Attacken. Beide sind also essentiell.

Kommentar von Jan K. |

Hallo,

vielen Dank für die Contao-Entwicklung.

Ich freue mich darüber, dass viele tolle Funktionen dazu kommen und einiges verbessert wird.

Ich fände auch toll, die oft benutzte und nötige Erweiterung Changelanguage (https://github.com/terminal42/contao-changelanguage) auch als Corestandard zu übernehmen. Contao ist zwar mehrsprachig, bietet aber in der Coreinstallation relative wenig an, um mehrsprachige Webseite umzusetzen. Eine eher typo3- bzw. i18nl10n-mäßige Handhabung fände ich auch mehr benutzerfreundlicher. :-)

Was denkt ihr?

Viel Erfolg!

Antwort von Yanick Witschi

Hi Jan,

Wenn du dir Änderungen am Core wünschst, solltest du am besten ein Ticket dazu erfassen :-)
Siehe https://github.com/contao/contao/.

Einen Kommentar schreiben

Bitte addieren Sie 9 und 9.