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:

In eigener Sache

Bis zum letzten Entwicklertreffen bestand das Contao-Kernentwicklerteam (oder kurz «Core Team») noch aus sechs Personen. Ab jetzt sind wir deren sieben und begrüssen Fritz Michael Gschwantner in unseren Reihen! Fritz dürfte den meisten Lesern sehr bekannt sein, denn unter dem Pseudonym «Spooky» ist er im Forum omnipräsent. Ausserdem ist Fritz auch Teil des Doku-Teams und bildet somit unsere Brücke sowohl zum Forum, als auch zur Doku. Eine echte Bereicherung für Contao und unser Team - herzlich willkommen, Fritz!

Dieses Mal haben wir auch noch Richard Henkenjohann zum Treffen eingeladen. Richard hat in der letzten Zeit auch einiges zu Contao beigetragen (z.B. die neue Frontend-Vorschau in Contao 4.9) und wir wollten den jungen Herrn ein bisschen näher kennenlernen.

Nebst Fritz und Richard nahmen die anderen sechs Dinosaurier, Andreas, Leo, David, Jim, Martin und meine Wenigkeit am Treffen teil, so dass also insgesamt acht Leute für drei Tage quasi ununterbrochen an Contao arbeiteten!

Community

Aufgrund der angekündigten Veränderungen innerhalb der Contao Association, haben wir uns einmal mehr Gedanken zur Contao-Community gemacht. Dries Buytaert, der Gründer und Projekt-Lead von Drupal, hat in einem sehr lesenswerten Blogpost die Drupal-Community analysiert und die Nutzer in sogenannte «Maker» und «Taker» unterteilt. «Maker» sind Leute, die in uneigennütziger Weise zum Projekt beitragen, also z.B. Code contributen, Doku schreiben, Events organisieren, im Forum helfen, und ähnliches. «Taker» sind reine Nutzer von Contao und dessen Ökosystems.

Es ist wichtig zu verstehen, dass dies eine wertfreie Analyse ist. «Maker» sind nicht automatisch gut und «Taker» schlecht. Und ein Open Source Projekt würde auch nicht funktionieren, wenn es nur aus «Makern» oder nur aus «Takern» bestünde. Die Mischung aus beidem macht es aus.

Für uns als Core-Team ist es wichtig – nicht zuletzt im Hinblick auf die neu zu besetzenden Positionen in der Association – ausreichend «Maker» zu haben. Denn auch mit Fritz als Verstärkung ist uns klar, dass das Core-Team zwar die Software Contao weiter entwickeln kann, aber nicht das Ökosystem am Laufen halten kann. Deshalb haben wir darüber diskutiert, wie wir unsere «Maker» noch besser unterstützen können bzw. wie wir Anreize schaffen können, weitere «Maker» zu gewinnen.

Grundsätzlich gibt es hier keine spruchreifen Resultate aber wir haben uns intensiv mit möglichen Verbesserungen auseinandergesetzt und Lösungsansätze gefunden. Insbesondere das gerechte Hervorheben von unseren «Makern» ist alles andere als einfach und hat uns bis tief in die Nacht hinein beschäftigt. Es ist uns aber eine Herzensangelegenheit, dass Leute die ehrenamtlich für Contao Zeit investieren, auch ihre wohlverdiente Anerkennung dafür erhalten.

Contao 5?

Unser letztes Entwicklertreffen stand noch ganz im Zeichen von Contao 4.9, unserer neusten LTS-Version. Ich hatte in meinem Blogpost zum damaligen Treffen bereits erwähnt gehabt, dass Stabilität das oberste Gebot für die LTS war. Wir haben deswegen auch bewusst gewisse Features weggelassen bzw. anderen vorgezogen. Ein gutes Beispiel hierfür wäre das neue Migrations-Framework. Es erschien uns enorm wichtig, das in der 4.9 LTS zu haben, weil unsere Entwickler ansonsten erneut zwei Jahre hätten warten müssen, da viele Contao-Nutzer ausschliesslich auf LTS-Versionen setzen.

Dieses Mal waren die Voraussetzungen allerdings ganz andere. Contao 4.9 LTS ist unsere neuste Version, sie läuft sehr stabil und wir sind stolz auf das Erreichte!

Es stellt sich nun also die Frage, «und jetzt?».

Um diese Frage zu beantworten, müssen wir ein bisschen ausholen und Contao 4 in seiner Gesamtheit betrachten.

Contao 4.0 erschien im Juni 2015. Ja, meine Freunde, das ist schon fast eine halbe Dekade her! Eine Ewigkeit in unserer Branche.

Fast fünf Jahre, in denen Contao stetig besser geworden ist. Aber nebst vielen Dingen, die wir verbessern konnten, gab es auch immer wieder Dinge, die sich als ungeschickt erwiesen haben. Altlasten, die mit jeder neuen Version mehr werden und wir weiterhin mitschleifen müssen, um höchstmöglichste Rückwärtskompatibilität mit Extensions sicherstellen zu können.

Auf Dauer wird das nicht tragbar sein. Irgendwann wird der Zeitpunkt kommen, an dem wir einen unwiderruflichen Schnitt ausführen werden müssen. Denn wer nicht in der Lage ist, Vergangenes zu vergessen, lebt irgendwann in der Vergangenheit. Und wir wollen nicht in der Vergangenheit leben. Wir wollen weiterhin offen für technologischen Fortschritt sein und am Puls der Zeit leben. Für uns ist daher klar, dass Contao 5 dieser Schnitt sein wird.

Doch wann ist der richtige Zeitpunkt und was bedeutet dieser Schnitt?

Contao 4 wurde lange angezweifelt. Viele User zeigten kein Verständnis für den Wechsel auf Symfony als Unterbau und «Composer» hätte als Kandidat für das Unwort des Jahres wohl ziemlich grosse Chancen gehabt.

Heute ist es anders, Contao 4 erfreut sich grosser Beliebtheit. Der neugewonnene Enthusiasmus war auf der letzten Contao-Konferenz deutlich spürbar. Composer ist dank des Contao Managers, der Composer Resolver Cloud und dem jetzt sichtbaren Nutzen mittlerweile in der Community akzeptiert und viele unserer Entscheidungen haben sich als richtig erwiesen. Wir haben also das Schiff erfolgreich durch den Sturm gelotst und befinden uns auf Kurs (ja, darauf bin ich besonders stolz!).

Diesen neu gewonnenen Schwung wollen wir auf keinen Fall bremsen. Deswegen sind wir der Meinung, dass der Zeitpunkt für Contao 5 noch nicht gekommen ist.

Wir möchten den bisher eingeschlagenen Weg weitergehen. Konkret bedeutet das, wir wollen weitere Problemstellen Schritt für Schritt angehen und neue, bessere Alternativen für den «alten Weg» anbieten.

Unser neues, langfristiges Ziel ist eine generelle API. Sie wurde schon oft diskutiert, aber wir müssen einfach zuerst die Grundsteine dafür legen. Wer ein Haus baut braucht ein starkes Fundament und davon sind wir zurzeit noch ein gutes Stück entfernt.

Nebst den Verbesserungen am Unterbau von Contao, um eben besagtes Fundament zu bauen, dürfen wir natürlich auch unsere Anwender nicht aus den Augen verlieren. Wir werden also auch hier mit jeder neuen Version von Contao darauf achten, auch Funktionen für Anwender mitzuliefern.

Vereinfacht gesagt haben wir also zwei grosse Themen für die kommenden Contao Versionen:

1. Wir wollen den technischen Unterbau immer weiter in Richtung API bringen. (Thema: API)
2. Wir dürfen unsere Anwender nicht vergessen und wollen mit jeder neuen Version auch etwas für sie einfliessen lassen. (Thema: User)

Dementsprechend wird unsere nächste Version Contao 4.10 sein und in folgenden Bereichen werden Änderungen erfolgen:

Erweiterbare Doctrine Entities (Thema: API)

Jim hat sich das ganze Treffen über mit Doctrine beschäftigt. Doctrine bildet den de-facto Industriestandard in der PHP-Welt für die Kommunikation mit der Datenbank und für ORM. Durch die Wichtigkeit in der PHP-Community existiert eine Vielzahl an bestehenden PHP-Bibliotheken, die die Umsetzung einer API auf Basis von Doctrine vereinfachen könnten.

Contao bringt mit «Models» seine eigene ORM-Lösung mit. Sie ist aber im Vergleich zu Doctrine deutlich einfacher gehalten. Bspw. verfügt sie über keine Unterstützung für n:m-Beziehungen. Sie hat aber einen entscheidenen Vorteil, nämlich dass beliebige Spalten in der Datenbank zu einem bereits existierenden Model hinzugefügt werden können. Das kann Doctrine nicht, ist aber für Contao unverzichtbar.

Folglich will Jim dafür sorgen, dass Contao Doctrine Entities erweitern kann.

Berechtigungen (Thema: API)

Meine Wenigkeit hat sich ausschliesslich mit unserem Berechtigungssystem beschäftigt. Leider ist es zurzeit so, dass das gesamte Berechtigungssystem in Contao zwar aus Anwendersicht sehr flexibel, aber in der technischen Umsetzung nicht sonderlich praktikabel ist. Der Grad der Wiederverwendbarkeit der bestehenden Routinen beträgt quasi null.

Wir müssen da also zuerst klar Schiff machen, bevor irgendwelche API-Anfragen in der Lage sein werden, Berechtigungen zu prüfen.

Oder um zurück auf die Hausbau-Methapher zu kommen: Der Umbau des Berechtigungssystems ist ein notwendiger Teil des Fundaments, um danach weitere Mauern darauf aufbauen zu können.

Symfony Mailer Integration (Thema: User)

Fritz hat sich mit der Migration von Swiftmailer zu Symfony Mailer beschäftigt. Symfony Mailer ist der offizielle Nachfolger von Swiftmailer bzw. dessen Ersatz. Er hat sich ausserdem mit den verschiedenen Möglichkeiten der Integration im Backend beschäftigt, mit dem Ziel, unterschiedliche E-Mail-Konfigurationen für unterschiedliche Zwecke (Formularversand, Newsletter etc.) verwenden zu können.

Ablösung des Install-Tools (Thema: User)

Ein weiteres langfristiges Ziel ist es, das Install-Tool (contao/installation-bundle) abzulösen und in den Contao Manager zu integrieren, bzw. für unsere Freunde der Kommandozeile, entsprechende Commands zur Verfügung zu stellen. Richard hat sich mit contao:user:list und contao:user:add Kommandos beschäftigt, welche den Grundstein für die Integration in den Contao Manager legen werden. Die letzte, noch übrig gebliebene Funktion im Install-Tool wäre danach der Theme/Template SQL-Import für den wir noch eine Lösung finden müssen. Hier denken wir über einen eigenen Composer Paket-Typen contao-theme nach, aber es gibt noch nichts Spruchreifes. Theme-Hersteller dürfen sich gerne auf GitHub einbringen und an Lösungen mitarbeiten.

Erweiterung der Routing-Einstellungen in der Wurzelseite (Thema: User)

Andy beschäftigt sich schon eine Weile mit der Integration der Einstellungen «Folder-URL», «URL-Suffix» und «Prepend Locale», in die Root-Seiten-Einstellungen. Dadurch wird es möglich, die Einstellungen nicht mehr systemweit zu treffen, sondern für jede Root-Seite und somit jede Domain individuell zu handhaben. Ausserdem haben wir uns dazu entschieden, die Sprache und das Sprachpräfix voneinander zu trennen. In Zukunft wird es also möglich sein, dem Seitenbaum zwar eine Sprache von einer vorgegebenen Liste zuzuweisen, dafür aber einen frei definierbaren Sprachpräfix zu verwenden. Wer also bspw. lieber alles unter /deutsch/foobar.html statt /de/foobar.html hätte, wird das in Zukunft problemlos tun können. Dadurch werden auch Varianten denkbar, bei denen bspw. der Englische Seitenbaum gar kein Präfix hat und alle anderen Sprachen ein Präfix verwenden.

Aufräumarbeiten, kleinere Verbesserungen

Martin hat dafür gesorgt, dass unsere pageTree und fileTree Backend-Widgets nicht mehr zwingend ein seperates Datenbank-Feld für die manuelle Sortierung erfordern. Die Sortierung wird neu im selben Datenbank-Feld wie die Auswahl selbst gespeichert. Die Ausnahme davon bildet weiterhin, wenn ganze Verzeichnisse im Dateiwähler ausgewählt wurden. Dann wird es weiterhin ein separates Feld für die Sortierung brauchen. Um das Handling zu vereinfachen, hat Martin ausserdem Helper-Methoden in der neuen ArrayUtil Klasse gebaut und direkt auch noch die ganzen alten Funktionen aus unserer uralten functions.php migriert bzw. als veraltet markiert und mit den besseren Alternativen ausgezeichnet.

Dave hat sich mit der Verbesserungen unserer statischen Code-Analyse beschäftigt und das PHPStan Level erhöht und sich mit der Integration von Psalm befasst, womit unsere Code-Qualität weiter steigen dürfte. Nebenbei hat er auch noch die Funktion eingebaut, Kalendereinträge hervorzuheben und danach zu filtern.

Ausserdem haben wir eine zweistellige Anzahl Bugreports für Contao 4.9 abgearbeitet.

That's all Folks!

Das nächste Entwicklertreffen findet voraussichtlich im September 2020 statt.

– Yanick

PS: Leo beschäftigt sich seit jeher mit dem Gegenlesen der Code-Kilometer und nimmt bei Fragen oder Unstimmigkeiten Rücksprache mit den anderen auf und merged die ganzen Pull Requests.