Contao-News

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:

Besondere Zeiten

Es sind wahrlich besondere Zeiten, in denen wir zurzeit leben. Ich verzichte darauf, gross auf die Situation einzugehen. Ich denke es versteht sich von selbst, dass auch das Core-Entwickler-Team von den aktuellen Umständen betroffen ist und unsere Köpfe nicht immer 100% da sind, wo sie vielleicht idealerweise gerade sein sollten.

Der widrigen Umständen zum Trotz haben wir es dennoch geschafft, uns zum zweiten Core-Entwicklertreffen 2020 zusammenzufinden.

PHP 8

Ende des Jahres erscheint die neue Major-Version von PHP und bringt viele neue Features und Verbesserungen mit sich. Die Herstellung der Kompatibilität mit PHP 8 steht ziemlich weit oben auf unserer Prioritätenliste. Das ist allerdings leichter gesagt als getan, denn eine Contao Managed Edition besteht mittlerweile aus über 150 einzelnen Paketen. Bei vielen werden wir davon profitieren, dass die PHP-Community die Arbeit für uns quasi übernimmt, aber bei einigen werden auch wir unseren Beitrag leisten müssen. Zudem sprechen wir von einer neuen Major-Version mit entsprechenden Änderungen die nicht rückwärtskompatibel sind. Martin und Leo haben sich intensiv damit beschäftigt und damit begonnen, unsere Testsuite auf PHP 8 anzuheben und eine ziemlich lange Liste an To-dos zu sammeln, bis es soweit sein wird.

Wichtig: Wir haben uns dazu entschieden, keine PHP 8-Kompatibilität für Contao 4.4 anzubieten. Contao 4.4 muss auch noch unter PHP 5.6 lauffähig sein und eine Kompatibilität über zwei Major-Versionen von PHP herzustellen, wäre noch deutlich schwieriger und aufwändiger zu erreichen. Gemäss unseres Release-Plans geht Contao 4.4 ungefähr mit dem Erscheinen von PHP 8 in die "Security"-Phase über und kann bis zu ihrem EOL Ende 2021 noch mit zwei bis dahin ebenfalls unterstützten PHP-Versionen (7.3 oder 7.4) betrieben werden. Unserer Meinung nach genügt das voll und ganz. Der Zusatzaufwand würde in keinem Verhältnis zu dem Wartungsaufwand für das Core-Team stehen.

Wer also in Zukunft PHP 8 nutzen möchte, wird ein Update auf die aktuelle 4.9 LTS oder die 4.10 bzw. 4.11 (je nach dem wann es halt soweit sein wird) vornehmen müssen.

"php": ">=7.2"

Wer die grösseren Projekte in der PHP-Welt aktiv verfolgt, wird womöglich mitbekommen haben, dass einige Projekte sich dazu entschieden haben, die Definition ihrer PHP-Mindestanforderung von beispielsweise ^7.2 auf >=7.2 zu ändern und damit den sogenannten "Upper Bound" zu entfernen. Sowohl Symfony als auch PHPUnit haben das unlängst getan.

Wir haben das Pro und Kontra ausgiebig diskutiert und sind zu dem Schluss gekommen, dass wir diesem Weg vorerst nicht folgen werden. Contao als Produkt lässt sich nicht direkt mit Frameworks wie Symfony oder PHPUnit vergleichen. Ausserdem kann man Abhängigkeiten auch heute schon mit dem Composer Flag --ignore-platform-reqs unabhängig der PHP-Version installieren, sollte jemand höhere PHP-Versionen testen wollen. In Composer 2.0 (welcher übrigens bereits in der RC-Phase ist und massive Performance-Verbesserungen mit sich bringt, zu denen wir auch einen wesentlichen Teil beigetragen haben) wird man ausserdem mit --ignore-platform-req=php spezifische Plattform-Abhängigkeiten ignorieren können.

Sicherheit

David hat sich mit weiteren Sicherheitsverbesserungen an Contao beschäftigt. Dazu gehört beispielsweise, dass unsere Backup-Codes für die Zweifaktorauthentifizierung in Zukunft gehasht in der Datenbank abgelegt werden. Das wird dazu führen, dass Backup-Codes nur noch beim initialen Erstellen eingesehen werden können. Wir haben uns verschiedene grössere Anbieter angesehen und einige gefunden, bei denen man die Backup-Codes ständig wieder einsehen kann und diese somit im Rohdatenformat hinterlegt sein müssen. Wir haben die gehashte Variante jedoch für sicherer befunden, was somit ab Contao 4.11 Standard werden wird.

Des Weiteren hat sich David auch mit der Erweiterung unserer Content Security Policy (CSP) beschäftigt. Er hat sich angesehen ob und wie wir die Integration in Contao verbessern könnten, so dass wir auch an dieser Front das Sicherheitslevel weiter erhöhen können.

Wenn man tief gräbt, findet man ab und zu leider auch Sicherheitslücken. Martin erging es so, weshalb er sich mit der Behebung einer Sicherheitslücke beschäftigt hat. Die entsprechenden Sicherheitsreleases wurden bereits separat angekündigt und die Composer Resolver Cloud wird mit deutlich erhöhter Kapazität bereit für euch sein.

Routing

Andy hatte ja bereits für Contao 4.10 das gesamte Routing in Contao überarbeitet. Für diejenigen, die die vorherigen Blogposts nicht gelesen haben: Routing bezeichnet den Prozess wie vom HTTP-Request die korrekte Zielseite gefunden wird. Nun ist er fleissig dabei, dieses Fundament zu nutzen und die ersten Wände darauf zu bauen. Ziel soll es sein, dass wir als Entwickler bald einmal URLs zu einem spezifischen Model direkt generieren lassen können. Ausserdem ist der Plan noch immer, dass Seitentypen eigene URL-Platzhalter definieren können sollen, so dass schliesslich URLs wie bspw. https://domain.de/news/<jahr>/<monat>/<alias>.html möglich sein werden.

Ferner wird es dank ihm in Zukunft möglich sein, ganze Locale IDs gemäss ICU-Standard zu definieren, so dass nicht mehr unsere zwei- bzw. fünfstelligen Sprachcodes zwingend sind. Eine Locale ID enthält nämlich nicht nur die Sprache, sondern auch Zusatzinformationen wie Dezimaltrennzeichen, Währungen und mehr.

Dynamische sitemap.xml

In Contao 4.9 haben wir einen echten Webcrawler eingeführt. Er durchsucht die gesamte Webseite nach Links und folgt diesen rekursiv weiter, so wie es auch die Crawler von Google, Bing und Co. tun. Seiten oder anderwertige Links, die dabei nicht über die Navigation auffindbar sind, können solchen Webcrawlern über die sitemap.xml mitgeteilt werden. Bisher wurden diese in Contao bei Änderungen im Backend generiert und in dem Verzeichnis share abgelegt. In der Rootseite konnte man dabei wählen, ob eine Sitemap erstellt werden soll und wie diese heissen soll. Das Problem dabei ist, dass geschützte Seiten in der sitemap.xml auftauchen müssten, damit unser Webcrawler diese findet. Für externe Crawler wie Google, Bing und Co. sind diese aber nicht relevant.

Diesem Problem habe ich mich angenommen. Neu ist es nicht mehr notwendig, die Sitemap explizit zu aktivieren und ihr einen Namen zu vergeben. Es wird automatisch pro Domain eine /sitemap.xml URL generiert, die sich um die korrekte Auslieferung der Sitemap kümmert und somit den Weg zur Behebung dieses Problems ebnet.

Ausserdem habe ich dafür gesorgt, dass die Entwickler einen neuen Event anstelle des altbekannten getSearchablePages-Hook nutzen können und die neue Invalidierungs-Logik mit unserem Caching-Framework hat den netten Nebeneffekt, dass Sitemaps nicht mehr im Backend generiert werden müssen und somit Performance-Verbesserungen an diesen Stellen zu erwarten sind.

API

Wir haben auch weiterhin das Ziel einer API nicht aus den Augen verloren.

Leo hat sich mit unserer Testsuite beschäftigt, damit unser Framework für Functional Test verbessert wird. Das ist eine Voraussetzung dafür, dass wir die bestehenden Backend-Berechtigungen testen können, bevor wir mit deren Umbau beginnen.

Jim hat an den Generated Doctrine Entities (bzw. im Prinzip jeglicher PHP-Klassen) weitergearbeitet.

All das klingt wenig spannend ist aber aufwändige Vorarbeit an unserem Fundament, ohne die eine allgemeine API nie Realität werden kann. Diese Themen wurden ausserdem schon in den vorherigen Blogposts etwas genauer beleuchtet.

Verschiedenes

Fritz blieb bisher unerwähnt, war aber natürlich auch sehr fleissig. Dank ihm gibt es bald eine neue rgxp-Anweisung im DCA für die Validierung von URLs, die mit http:// oder https:// beginnen. Ausserdem wird es eine Möglichkeit geben, bequem eigene Reguläre Ausdrücke nutzen zu können, ohne dafür extra einen save_callback oder addCustomRegexp-Hook registrieren zu müssen.

Daneben hat er sich damit beschäftigt, wie wir alternative Akkordeon-Scripte ohne jQuery oder MooTools nutzen können.

Jims "maker-bundle" macht auch Fortschritte. Wir gehen davon aus, dass es das nächste Bundle wird, das mit den anderen Core-Bundles in unserem Monorepository gepflegt werden wird. Das "maker-bundle" soll dasjenige von Symfony um Contao-spezifische Vorlagen erweitern.

Im Plenum haben wir auch die weiteren Schritte für die Abschaffung des Install-Tools besprochen. Der letzte grosse Baustein hier ist die Verwaltung von Themes. Das Anlegen von Administratoren und die Datenbankmigrationen wurden ja bereits über die vergangenen beiden Contao-Versionen auf der Kommandozeile eingeführt, so dass der Contao Manager diese Arbeiten in Zukunft übernehmen kann. Hier haben wir einige Ansätze besprochen und uns auf eine grundsätzliche Stossrichtung geeinigt, für deren Umsetzung aber schlussendlich die Zeit gefehlt hat.

Bugfixes

Wie immer haben wir uns auch mit Bugreports beschäftigt, die etwas zeitintensiver sind oder deren Lösungsansätze besprochen werden wollen. Einige davon konnten wir abarbeiten, so hat Fritz beispielsweise dafür gesorgt, dass der Picker vorausgewählte Elemente beim Editieren nicht mehr "vergisst".

That's all Folks!

Das nächste Entwicklertreffen findet voraussichtlich im Februar 2021 statt, aber wer weiss schon, was nächstes Jahr sein wird.

Nutzt die 1.5kg Hirnmasse zwischen euren Ohren, schenkt einander ein Lächeln, bleibt rücksichtsvoll und gesund!

– Yanick