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. Mitglied werden und uns somit unterstützen kann man hier.

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:

Ökosystem

Wie bei jedem Treffen unterhalten wir uns nicht nur zu Contao als Software an sich, sondern auch über dessen Ökosystem.

Englisch

Ein wichtiger Entscheid den wir getroffen haben, ist dass wir uns wieder vermehrt der englischen Sprache widmen möchten. Beliebte Blogserien wie diese Zusammenfassung der Entwicklertreffen wie auch der zweimonatige Contao Rückblick werden deshalb in Zukunft auch in Englisch erscheinen.

Ein neues Repository «contao/conflicts»

Ein neues Repository namens «contao/conflicts» findet Einzug im Contao-Universum. Für die Nutzer des Contao Managers wird es in der zukünftigen Version automatisch im Hintergrund geladen. Alle Nutzer die gerne ohne den Manager auf Kommandozeile arbeiten möchten, können sich das Paket wie auf GitHub dokumentiert installieren.

Hintergrund: Im Gegensatz zu früheren Contao-Versionen verwaltet der Seitenadministrator nicht mehr einfach nur Contao sondern eine Symfony-Applikation. Contao selbst ist eine Abhängigkeit dieser Applikation wie jede andere auch. Das hat den immensen Vorteil, dass wir Bibliotheken wiederverwenden können aber auch den Nachteil, dass wir nicht alle Releases der Abhängigkeiten kontrollieren können. In jüngster Zeit hatten wir gerade mit doctrine/dbal einige Probleme, weil deren Releases zum Teil Scherereien bereiteten und ein normales Contao Bugfix-Update zerstören konnten. Wir mussten dann die User darum bitten, entsprechende «conflicts» in ihrer composer.json einzutragen, damit diese Pakete eben nicht installiert werden. Mit der Einführung eines zentralen «contao/conflicts» Pakets, haben wir nun die Möglichkeit für unsere User an einem zentralen Ort in den Abhängigkeitsauflösungsprozess einzugreifen, so dass im Idealfall die grosse Mehrheit der User das gar nicht mitbekommen wird bzw. wir die Konflikte verwalten können.

Dokumentation

Seit ich mich erinnern kann, ist die Dokumentation ein immerwährendes Thema im Contao-Umfeld. Jeder will sie aber keiner schreibt sie. An der vergangenen Generalversammlung der Contao Association wurde aber erstmals Budget für die Erarbeitung einer Dokumentation gesprochen. Wir haben dieses Jahr deshalb Fritz und Bjarke zum Entwicklertreffen eingeladen, die sich zusammen mit Jim und meiner Wenigkeit intensiv der Dokumentation gewidmet haben. Das Dokumentations-Framework auf der Basis von Hugo steht und wird aktuell mit Inhalt befüllt. Wir sagen jetzt schon vielen Dank dafür, dass sie sich die Zeit genommen haben, uns in Zürich zu besuchen!

Es wird ein Benutzerhandbuch in englischer und deutscher Sprache geben. Hinzu kommt eine Entwicklerdokumentation die ausschliesslich in englischer Sprache geschrieben wird.

Erste Resultate sahen vielversprechend aus! Die Entwicklerdokumentation ist bereits jetzt auf einem Stand von dem wir bisher nur träumen konnten.

Das Ziel ist es, zum Contao Camp in München die Dokumentation zu veröffentlichen, damit die ganze Community daran arbeiten kann. Aktuell wäre das noch etwas verfrüht weil beispielsweise die Dokumenation dazu wie dokumentiert werden muss noch fehlt :-)

An dieser Stelle möchte ich zwei persönliche Kommentare einfliessen lassen:

1. Die besagten Geldmittel sind verhältnismässig gering und zu erwarten, dass sich die Dokumentation jetzt einfach von alleine schreibt wäre, vorsichtig ausgedrückt, ziemlich vermessen. Es reicht allenfalls um sich um die Infrastruktur und den roten Faden in einer Dokumentation zu kümmern, aber ein Grossteil der Beiträge muss immer noch von der Community kommen. Wir sind und bleiben ein Community-Projekt.
2. Seit 12 Jahren ist die Dokumentation ein omnipräsentes Thema auf den Konferenzen, Camps etc. und ich finde hier bietet uns gerade eine grossartige Chance dem endlich ein Ende zu bereiten. Wir haben endlich motivierte Leute die garantiert auf der Suche nach Mitstreitern sein werden. Wenn ihr also von jemandem für Unterstützung angesprochen werdet, wisst ihr was zu tun ist. Auch das Core-Team ist sich der Wichtigkeit der Dokumentation für das Projekt bewusst und wird in Zukunft gerade bei der Entwicklerdokumentation seinen Teil dazu beitragen.

Autoupdates

Aufgrund von Inputs aus der Community haben wir uns auch mal wieder über die Realisierbarkeit von automatischen Updates unterhalten. Das Thema war aber relativ schnell vom Tisch, weil kein Team-Mitglied Autoupdates für zielführend hält. Die potenziellen Stolperfallen und unsere Sicherheitsbedenken sind schlichtweg zu gross. Dank Composer und ggf. dem Contao Manager hat sich der Aufwand ja auch bereits stark reduziert.

Zweifaktor-Authentifizierung für das Frontend

Dave hat sich das gesamte Treffen über mit der Zweifaktor-Authentifizierung für das Frontend auseinandergesetzt. Die grosse Schwierigkeit hierbei ist – wie so oft – die grosse Flexibilität von Contao, welche es uns erlaubt, Login-Module auf beliebigen Seiten zu platzieren. Eine gute Mischung zwischen Modulen und ggf. Seitentypen zu finden stellt sich als schöne Herausforderung dar. Auch mussten zuerst vorbereitende Massnahmen wie Pull Requests an Drittanbieter-Bundles vorgenommen werden, um überhaupt an eine Integration in Contao zu denken.

Eine erste Version hat er uns kurz vor Ende des Treffens vorgeführt. Alles noch ein bisschen holprig, aber es hat funktioniert.

Früher oder später dürfte 2FA für's Frontend in Contao also eine Tatsache werden!

Verzögertes Generieren der Vorschaubilder

Seit jeher werden die Vorschaubilder in Contao während des ersten Seitenaufrufs generiert. Das hat den gravierenden Nachteil, dass wenn der Bilder-Cache noch nicht aufgebaut ist, die Ladezeit der Seite unter Umständen sehr schlecht ist. Das mögen weder Suchmaschinen noch wir als Besucher. Im schlimmsten Fall läuft der Request sogar in ein Timeout, so dass der Benutzer die berühmte «weisse Seite» sieht. Bekannt geworden etwa durch die Dateiverwaltung, wenn ein Verzeichnis mit vielen Bildern geöffnet wurde.

Durch die Einführung von responsiven Bildern wurde die Performance gerade im Frontend zusätzlich verschlechtert.

Über die vergangenen 1.5 Jahre haben wir an einem Konzept gearbeitet, wie wir diese Problematik potenziell lösen können und Martin hat sich nun dieser Aufgabe angenommen und unser erarbeitetes Konzept scheint tatsächlich zu funktionieren! Während des Requests wird das Bild nicht generiert sondern nur dessen Hash berechnet und zusammen mit den Bildeinstellungen in einem Cache abgelegt. Wenn das Bild nicht in assets/images liegt, wird der Server den Request automatisch auf Contao umleiten womit wir den Hash im Cache suchen und das Bild erst jetzt generieren können. Das Verkleinern der Bilder geschieht dann nicht mehr im Seitenrequest sondern im Request auf das eigentliche Bild. Das klingt relativ einfach, involviert aber z.B. auch einen Lock-Mechanismus, weil ggf. mehrere Requests zur selben Zeit das selbe noch nicht verkleinerte Bild anfragen uvm.

Aber die Implementierung ist sehr weit fortgeschritten und ich denke ihr könnt euch ziemlich sicher auf einen maximalen Performance-Boost in Contao 4.8 freuen!

Komplett neues Konzept für Entrypoints und die Frontend-Vorschau

Unsere aktuelle Contao Managed Edition stellt zwei sogenannte «Entrypoints» zur Verfügung: Die app.php und die app_dev.php. Die produktive Umgebung läuft dann auf z.B. https://www.domain.de/seite.html und um den Debug-Modus zu erreichen, würde man https://www.domain.de/app_dev.php/seite.html aufrufen. Diese Situation ist aus folgenden Gründen unbefriedigend:

• Um in den Debug-Modus zu gelangen, muss man zuerst via Kommandozeile oder via Contao Manager aus Sicherheitsgründen ein Passwort vergeben und danach manuell app_dev.php in die URL schreiben. Das ist etwas umständlich.

• Durch den Reverse Proxy Cache haben wir das Problem, dass https://www.domain.de/seite.html womöglich bereits im Cache abgelegt wurde, aber sowohl für die Frontend-Vorschau als auch für den Debug-Modus darf diese Seite nicht aus dem Cache geladen werden, denn dann würde man ja nie den gewünschten Inhalt erhalten. Man stelle sich jetzt aber vor, man nutze nicht den mitgelieferten PHP-Reverse Proxy sondern einen externen, wie Varnish: Dieser hat keine Möglichkeit zu wissen, ob ein User gerade eingeloggt ist, da er nicht innerhalb der selben Applikation läuft. Insofern ist das zurzeit technisch extrem kompliziert gelöst indem vor jedem eigentlichen Request ein zusätzlicher Request abgesetzt wird. Dabei wird die Applikation gefragt, ob gerade ein User eingeloggt ist, um allenfalls den Cache zu umgehen (für die Entwickler: Stichwort header-replay-bundle). Diesen zusätzlichen Request kann theoretisch jeder Reverse Proxy absetzen und wir haben so eine allgemeine Lösung für beliebige Proxies. Sie ist aber schlichtweg zu kompliziert, das heisst das header-replay-bundle muss weg und das wiederum bedeutet, wir brauchen eine andere Lösung für unsere Entrypoints und wir können das mobile Seitenlayout nicht mehr in der aktuellen Form unterstützen.

Andy und ich hatten seit längerer Zeit ein Konzept im Kopf, wie das in etwa aussehen könnte und haben nun angefangen, das in die Tat umzusetzen. In etwa dürfte das dann so aussehen:

• Wir werden neu eine index.php und eine preview.php haben. Jegliche Requests auf preview.php werden dabei nie im Cache abgelegt. In unserem Beispiel würden wir die Frontend-Vorschau also neu via https://www.domain.de/preview.php/seite.html aufrufen. Natürlich geschieht das alles automatisch durch Klick auf die Frontend-Vorschau im Backend.

• Die index.php prüft ob der Request ein Cookie oder Authorization Header enthält und umgeht in diesem Falle den Reverse Proxy Cache komplett. Für externe Proxies wie Varnish bedeutet das eine deutliche Vereinfachung der Konfiguration. Keine zusätzlichen Requests mehr. Für Contao bedeutet das, dass wir das header-replay-bundle und somit eine grosse Komplexität und Hürde beim Debugging loswerden.

• Der Debug-Modus wird neu bequem per Klick im Backend aktivierbar sein. Für den Fall, dass Contao nicht lauffähig ist, muss das aber auch weiterhin via Contao Manager möglich sein. Funktionieren wird das über ein JSON Web Token.

• Das mobile Seitenlayout wurde bereits in ein eigenes Bundle ausgelagert (voraussichtlich contao/mobile-page-layout-bundle) womit die Funktion im Core in Contao 4.8 entfällt. Es kann aber dazu installiert werden, für diejenigen, die immer noch auf diese Funktion angewiesen sind. Wird dieses Bundle installiert, so werden aber implizit jegliche Seiten-Cache-Einstellungen ignoriert und Caching komplett deaktiviert.

• Die aktuelle iFrame-Lösung in der Frontend-Vorschau dürfte über kurz oder lang einer moderneren und hübscheren JavaScript Toolbar weichen.

Routing-Einstellungen in den Root-Seiten

In Contao 4.7 hat Andy das komplette Routing auf den Symfony CMF Router umgestellt. Das war ein riesiger Pull Request aus dem wir aber noch keine Vorteile gewonnen haben, ausser möglicherweise Performance (uns liegen noch keine konkreten Benchmarks vor) und der automatischen Umleitung auf https://, wenn die entsprechende Checkbox in den Seiteneinstellungen angewählt wurde. Zeit das zu ändern! In Zukunft wird es deshalb wohl keine prepend_locale Einstellung mehr geben, denn folgende Einstellungen sollen in die Root-Seiteneinstellungen wandern und deshalb neu pro Domain anstatt pro System gepflegt werden können:

• Ordner-URLs verwenden
• Sprachkürzel zur URL hinzufügen
• URL-Suffix
• Leere URLs nicht umleiten

Auch hier durften wir bereits einen ersten Entwurf sehen und es scheint so als wäre das tatsächlich machbar!

Scheitern gehört dazu

Wichtig zu erwähnen, scheint mir auch, dass wir uns nicht immer einfach hinsetzen und etwas Tolles bauen können. Manchmal scheitern wir auch. Deswegen gibt's ab jetzt in dieser Blogserie auch einen Abschnitt dazu:

• Leo, der sich meistens das ganze Treffen über mit den Pull Requests der anderen beschäftigen muss, fand trotzdem auch noch die Zeit an einem neuen Feature zu arbeiten und hat sich mal wieder an DCAs in YAML schreiben versucht. Leider ein Fass ohne Boden, insbesondere wegen der Referenzen auf Superglobalen. Da ist also im Moment leider keine Lösung in Sicht.

• Martin hat sich mit Drag n' Drop für den Seitenbaum etc. beschäftigt. Auch da ist im Moment keine Lösung am Horizont, insbesondere wegen der Berechtigungen. Seiten können nicht in beliebige andere Seiten verschoben werden. Die Berechtigungen dazu werden aber im Moment erst beim Absenden geprüft und dann gibt es die button_callbacks mit denen Entwickler beliebige Logik implementieren können usw.

So, Ende des Romans :-)

Ich bin dieses Mal extrem euphorisch! Die Liste der Features ist super lang und grossartig! Wir wissen zwar noch nicht was alles davon bereits in Contao 4.8 verfügbar sein wird und ob dann alles so wird wie zum Zeitpunkt dieses Blogbeitrags beschreiben, aber am liebsten hätte ich Contao 4.8 heute schon! Naja, es ist ja bekanntlich gesund, wenn man etwas hat worauf man sich freuen kann :-)

Das nächste Entwicklertreffen findet voraussichtlich im August 2019 statt.

Aber vorher sehen wir uns alle auf dem Contao Camp am 18. und 19. Mai in München!

– Yanick