Get the MOST

Im Symfony-Ökosystem werden Frontend-Komponenten seit einiger Zeit zunehmend über UX-Komponenten verarbeitet. Auch wenn hierdurch einige Anbelange vereinfacht werden, ist doch oftmals der Aufbau einer JavaScript Toolchain mit Node usw. notwendig, um etwa mit Symfony Webpack Encore zu arbeiten.

Durch neue Browser-Funktionen muss das nicht mehr zwingend der Fall sein. Die mit Symfony 6.3 neu eingeführte AssetMapper-Komponente hilft mit sogenannten ImportMaps dabei, die Komplexität noch einmal deutlich zu reduzieren: durch eine JSON-Datei wird auf sehr einfache Weise angegeben, welche Assets der Browser laden soll. Um JS-Dependencies aufzulösen, wird statt npm oder yarn ein Symfony CLI-Kommando ausgeführt.

Vor kurzer Zeit haben wir das EasyAdminBundle (EAB) in die Entwicklungsversion von Zikula 4 integriert um das alte Admin-Interface abzulösen. Seitdem beobachten wir natürlich stets, was sich bei diesem Bundle an neuen Innovationen ergibt.

Eine schöne neue Funktion wurde vor kurzem fertiggestellt und wartet aktuell darauf, eingebunden zu werden: mit einem Column chooser wird es möglich, sich nur ausgewählte Tabellenspalten anzeigen zu lassen und die Spalten darüber hinaus frei zu sortieren.

Im Rahmen der Schlankheitskur vom Zikula Core sind einige Altlasten bereits entfernt worden. Das Admin-Interface baut nun auf dem EasyAdminBundle auf.

Ein größerer Knoten, den es noch zu entwirren gilt, betrifft die miteinander zusammenhängenden Themen Benutzer, Gruppen, Rechte, Rollen, Security. Dieser Beitrag beleuchtet unsere damit einhergehenden Gedankengänge und zeigt auf, welchen Plan wir für die nächsten Schritte verfolgen wollen.

Wo kommen wir her?

Seither wurden die relevanten Funktionen in Zikula durch folgende Bausteine bereitgestellt:

Im letzten Beitrag wurde unter anderem dargestellt, dass Zikula 4 nun das EasyAdminBundle (EAB) integriert um das alte Admin-Interface abzulösen. Zwischenzeitlich sind die Arbeiten daran etwas fortgeschritten.

Änderungen im Zikula Core

Zikula bietet in seinem ThemeBundle per Standard ein UserDashboard und ein AdminDashboard, die beide das Site Branding verwenden. Diese können leicht in einem Projekt angepasst und erweitert werden. Darüber hinaus ist es natürlich möglich, weitere Dashboards hinzuzufügen, um spezifische Sichten für weitere Gruppen bereitzustellen.

Getreu dem Motto Wer loslässt, hat die Hände frei wird der Zikula Core gegenwärtig ausgemistet: das Ziel ist es, wieder ein schlankes System zu schaffen, welches nicht jede Funktionalität selbst anbieten möchte, sondern sich hierfür noch mehr dem Symfony Ökosystem öffnet. Seit dem letzten Beitrag wurde weiter Ballast abgeworfen - die Änderungen aus den letzten zwei Wochen werden im Folgenden dargestellt.

• Das OAuthBundle ist entfernt worden; das ist ein Vorgeschmack darauf, dass Zikula keine eigene Methodik zur Authentifizierung anbieten, sondern sich mehr an das Security-System von Symfony halten sollte. Für selbiges gibt es Dutzende von Bundles, welche diverse Möglichkeiten zur Authentifizierung zur Verfügung stellen.
• Das WorkflowBundle ist ebenfalls rausgeflogen; die verbleibende Funktionalität, die es erlaubt, dass Workflow-Definitionen an unterschiedlichen Orten, zum Beispiel direkt in einem Bundle, liegen können, wurde beibehalten und in das CoreBundle verschoben.
• Das eigene Extension-System ist nun entfernt worden: Bundles werden nun ausschließlich über Composer und Flex verwaltet. Eine Besonderheit: als Relikt der früheren Installer gibt es im CoreBundle ein InitializableBundleInterface: mit einem Konsolen-Kommando zikula:init-bundle können so Tasks ausgeführt werden, die nach der Einrichtung eines Bundles mit Flex noch zu tun sind. Hierzu zählt etwa das Einspielen von ersten Daten oder die Integration mit dem CategoriesBundle.
• Einige Bestandteile der bisherigen Distribution wurden zurück in das Core-Repository / Monorepo geholt: im Moment wieder drin sind LegalBundle, ProfileBundle und StaticContentBundle.
• Alle verbleibenden Module wurden grundsätzlich auf Bundles umgestellt.
• Das RoutesBundle und damit das eigene Routing-System wurden komplett entfernt, wie im letzten Beitrag bereits in Aussicht gestellt worden war.
• Es gibt keine Variablen (ModVars) mehr: statt dessen wird die Config-Komponente von Symfony zur Definition von Bundle Configurations verwendet.
• Auch die CapabilityApi aus dem ExtensionsBundle musste weichen: wieder eine Konvention weniger, die kein Bundle, das für plain Symfony gebaut worden ist, erfüllen können wird.
• Alle Referenzen zum Zikula-Kernel wurden abgebaut. Meistens wird gar nicht der Kernel an sich, sondern nur ein Parameter benötigt, der dann direkt injiziert werden kann. Ansonsten sollte nun eine Kernel Injection mit dem Type Hint auf den Symfony Kernel versehen werden.
• Das alte Admin-Interface wird im Moment durch das EasyAdminBundle und entsprechende Dashboards abgelöst. Hierbei sind bereits das AdminBundle und die Reste vom ExtensionsBundle rausgeflogen. Übrigens bringt das neue Admin-Interface nun auch eine neue Suchfunktion mit.
• Die Theme-Engine wird deutlich schlanker: ein Theme ist nun vom Konzept her kein eigenes Bundle mehr, sondern ein eigenes Dashboard, welches entsprechend eigene Templates und Assets verwenden kann. Im ThemeBundle wurde hierfür außerdem das ExtensionMenuInterface umgebaut, so dass ein Bundle nicht mehr Knp-Menüs, sondern Dashboard-MenuItems bereitstellen kann. Über das EasyAdminBundle werden nun unter der Haube Bootstrap 5 und FontAwesome 6 verwendet. Auch das Asset Handling läuft moderner, so gibt es etwa eine automatische Versionierung der Assets und sie werden komplett von Encore/Webpack verwaltet. Eigene Theme-orientierte Konzepte sind hierdurch obsolet geworden, zum Beispiel Page-Variablen und Theme-Variablen sind weggefallen.

Aktuell laufen noch die Integrationsarbeiten mit dem neuen Admin-Interface. Natürlich werden wir wieder hier berichten, nachdem die nächsten Meilensteine erreicht worden sind.

Im Juli haben wir noch etwas zaghaft damit begonnen, historischen Ballast aus dem Zikula Core zu entfernen. Unter anderem wurden spezielle Themes und das Hook-System ausgesondert. Während der letzten Tage hat die Konsolidierung nun Fahrt aufgenommen. Dieser Beitrag fasst kurz zusammen, was bisher passiert ist.

• Eine Vielzahl von Repositories für Content-getriebene Erweiterungen wurde archiviert. Schon vor 10 Jahren wurde die Frage gestellt, ob Zikula ein Content Management System oder ein Framework ist. Da die Community gemischt war und Vertreter unterschiedlicher Zielgruppen beinhaltet hatte, konnte das nie eindeutig geklärt werden, weswegen alles versucht, aber nichts fokussiert vorangetrieben worden war. Das hatte dazu geführt, dass bei sinkender Manpower weiter versucht wurde, ein größeres Ökosystem dauerhaft zu warten. Das ist nun Geschichte: wie bereits erwähnt wird mit Zikula 4 ohnehin Symfony die Führung übernehmen. Ob dann Zikula-Erweiterungen mit Symfony selbst oder auf einem darauf basierenden Content Management System (wie etwa Bolt oder Sulu) verwendet werden, ist Geschmackssache bzw. hängt von der Ausrichtung des jeweiligen Projektes ab. Es ist vorgesehen, dass ModuleStudio-basierte Bundles entsprechend in verschiedenen Szenarien einsetzbar sind. Es macht aber keinen Sinn, dass wir versuchen, Erweiterungen für Inhaltspflege, Blogsysteme, Medienverwaltung, Bewertungen usw. usf. zu pflegen - denn davon gibt es im Symfony-Ökosystem genug zur Auswahl. Betroffen sind hier beispielsweise Content, Eternizer, EZComments, Formicula, Media, MultiHook, Multisites, News, PageLock, Pages, Ratings, Reviews, Scribite und noch viele weitere.
• PageLock ist entfernt worden - sowohl aus dem Core als auch aus dem Generator.
• Das veraltete BootstrapTheme ist ebenfalls rausgeflogen zu Gunsten seines Nachfolgers DefaultTheme.
• Der Core hat nun keinen eigenen Installer mehr, in diesem Zuge wurde auch der ohnehin als veraltet gekennzeichnete YamlDumper überflüssig.
• Das Search-Modul ist weg, denn es war eines der Dinge, die wir bei Zikula nicht besser konnten als andere, die aber dafür gesorgt haben, dass Zikula-Module immer noch anders arbeiteten als normale Symfony Bundles. Wenn man eine Suchfunktion braucht, kann man zum Beispiel ElasticSearch verwenden. Auch die RouteUrl-Klasse sowie das dazugehörige UrlInterface konnten hiermit entfallen.
• Das Pending Content System wurde entfernt.
• Dynamische Menüs können nicht mehr datenbank-basiert definiert werden. Die angepassten Templates für das verwendete KnpMenuBundle bleiben erhalten und werden voraussichtlich in die Theme Engine verlagert.
• Das in die Jahre gekommene PHPIDS wurde aus dem SecurityCenter-Modul entfernt. Die Empfehlung lautet hier, eine WAF (Web Application Firewall) auf Serverebene zu nutzen, anstatt so etwas innerhalb der Applikation zu adressieren.
• Im Routes-Modul können keine eigene Routen mehr erstellt werden. Das eigene/angepasste Routing-System wird ebenfalls noch ausgebaut werden, um hier dem Symfony-Standard voll zu entsprechen.
• Das Blocksystem wurde entfernt. Auch dies ist so eine Sonderlocke, die sehr historisch motiviert ist (das gab es ja schon zu xxxNuke-Zeiten). Die Anforderung, dass jedes Modul bestimmte Funktionen in Form von Blöcken bereitstellen muss, wirkt auch aus der Zeit gefallen: in Symfony lässt sich jede Response an beliebiger Stelle einbinden. Übergangsweise haben wir das Hauptmenü und den Sprachwechsel fix im Theme eingebunden.
• Auch Modul-Abhängigkeiten sind nicht mehr vorhanden. Das Extension-System wird aber noch weiter rückgebaut, da Erweiterungen nur noch mit Composer und Flex verwaltet werden sollen. Das ist einer der nächsten Punkte auf der Liste.
• Das Mailer-Modul wurde entfernt, schließlich hat es einen größeren Aufwand getrieben, nur um eine Umgebungsvariable (MAILER_DSN) zu setzen. Die Funktionalität zum Testen des Mailversandes bleibt erst einmal bestehen, sie wurde in das Settings-Modul verschoben.
• Die eigenen Maker zum Erstellen von Zikula-Erweiterungen sind rausgefallen.

Wir werden wieder hier berichten, nachdem die nächsten Schritte gemacht worden sind.

Stimulus und Symfony UX

Ein JavaScript-Ökosystem für Symfony wurde bereits Ende 2020 gestartet. Vereinfacht ausgedrückt wurde Symfony Flex erweitert, um auch JavaScript-Anteile in einem Bundle leicht konfigurieren und einrichten zu können. Dazu wird eine Integration mit Stimulus verwendet. Diese Struktur führt zu einer zunehmenden Standardisierung und Aufteilung in wiederverwendbare UX-Komponenten.

Seitdem ist eine Menge passiert: nach Webpack Encore 1.0 und Stimulus Bridge 2.0 kam Symfony UX Turbo, das auf der Basis von Turbo das Schreiben von JavaScript in vielen Fällen überflüssig macht. Anschließend gab es noch einen weiteren Versionssprung, so dass wir aktuell bei Symfony UX 2.0 und Stimulus 3 stehen.

Bereits vor einiger Zeit sind die Gedankengänge gereift, in welche Richtung sich der Zikula Core 4 bewegen wird. Die wohl wichtigste Änderung besteht darin, dass Zikula nicht mehr Symfony und verschiedene Drittanbieter-Ergänzungen beinhaltet, sondern Erweiterungen für Symfony bereitstellt. Zikula-Bundles können dann wie jede andere Erweiterung mit Composer und Flex eingebunden werden. Das löst einige Knoten, da so das Ökosystem von Symfony einfacher verwendet werden kann, anstatt Lösungen für alle möglichen Anliegen in Zikula selbst bauen zu müssen.

Heute sind gleichzeitig zwei neue Versionen vom Zikula Core veröffentlicht worden.

Zikula 3.0.4 bringt Fehlerkorrekturen

Mit der Version 3.0.4 wird ein weiteres Bugfix-Update für die Hauptversion 3 bereitgestellt.

Die Änderungen im Detail werden in der Release-Ankündigung aufgelistet.

Zikula 3.1.0 hat etwas mehr an Bord

Außerdem ist auch Zikula Core 3.1.0 erschienen; dieses Update beinhaltet zusätzlich einige Neuerungen, bringt aber auch Veränderungen mit.

Auch hierfür gibt es eine detaillierte Liste mit den Korrekturen, hinzugefügten Features und sonstigen Neuerungen.

In Zikula gibt es eine Besonderheit zu beachten, welche Einfluss darauf nimmt, wie die aus einem Request resultierende Response zum anfragenden Client gelangt.

Per Standard wird die Response in Symfony im Rahmen einer Controller-Aktion erstellt und zurückgeliefert. Gegebenfalls wird die Response noch von einem oder mehreren Event Subscribern verändert.

Bei Zikula wird noch eine Theme-Schicht dazwischen geschaltet, welche den Inhalt der Response in eine neue Response überführt, um den Layout-Rahmen sowie damit einhergehende, zusätzliche Blöcke usw. zu rendern.