Get the MOST

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.

Mit dem Build-System Nx lassen sich beliebige Projekte in einem Monorepo auf einheitliche Weise testen und bauen. Es bedient sich verschiedener npm-Plugins, um dies für unterschiedliche Technologien umzusetzen. Ein Projekt kann dabei entweder als Applikation oder als Bibliothek abgebildet werden. Dies kann für ein Java-basiertes Projekt etwa durch Maven oder Gradle erfolgen.

Um ein einzelnes Projekt zu testen oder zu bauen, reicht ein Aufruf in der Form nx test <app> bzw. nx build <app>. Durch die Möglichkeit, dass Projekte Abhängigkeiten untereinander deklarieren können, kann dies auch transitiv geschehen. Nachdem ein Projekt gebaut worden ist, werden die Builds von abhängigen Projekten ebenfalls durchgeführt.

Nach dem Ende März erfolgten Kubuntu-Upgrade auf Jammy Jellyfish blieb das Problem, dass sich KeePassXC nicht mehr automatisch in dem nun auf Snap umgestellten Firefox-Browser integriert betreiben lässt.

Normalerweise arbeitet die Integration zwischen Browser und Passwort-Manager mit Hilfe eines Browser-Plugins: hierüber fragt der Browser die benötigten Daten an. Da sich das KeePass jedoch außerhalb der Sandbox befindet, ist dies aus Sicherheitsgründen nicht mehr zulässig.

Abhilfe schaft hier eine Funktion namens Auto-Type: hiermit fungiert KeePassXC im Prinzip als Tastatur und schreibt so Benutzername und Kennwort aktiv von außen in das entsprechende, aktuell geöffnete Login-Formular. Das Ganze funktioniert direkt out of the box - aus Convenience-Gründen habe ich lediglich noch ein Tastaturkürzel eingestellt, um die Funktion auf Knopfdruck starten zu können.

Der Symfony Messenger kann über unterschiedliche Transporte mit diversen Queue-Technologien eingesetzt werden, zum Beispiel AMQP, Redis, Amazon SQS oder Doctrine. Um die Messages in den Queues anschauen zu können, stehen je nach Anbieter verschiedene Möglichkeiten zur Verfügung. So bietet etwa RabbitMQ eine Management-UI, mit der unter anderem solche Aufgaben erledigt werden können.

Sofern Bedarf entsteht direkt in Symfony zu erfahren, wie voll eine bestimmte Queue ist oder welche Nachrichten sich darin befinden, könnte sich das messenger-monitor-bundle anbieten. Es erlaubt die Größe der Queue in der Konsole in einem einstellbaren Intervall zu verfolgen. Auch eine UI mit diversen Statistiken ist verfügbar: so werden zum Beispiel die Anzahl der Nachrichten pro Stunde, die durchschnittliche Wartezeit und Bearbeitungszeit dargestellt.

In Symfony gibt es mit der Mime-Komponente eine komfortable Möglichkeit, MultiPart-Nachrichten zu erstellen. Nicht out of the box enthalten ist aber ein Interface, das den Zugriff auf die in eingehenden MultiPart-Requests enthaltenen Bestandteile erlaubt.

Diese Lücke füllt das MultipartUpload-Bundle. Mit einem Event-Listener, der auf das Kernel-Event kernel.request hört, werden eingehende Requests daraufhin untersucht, ob sie mehrere Parts beinhalten. Ist dies der Fall, werden die einzelnen Teile extrahiert und in Request-Attributen bereitgestellt.

Da die zu Grunde liegende Logik mittlerweile in einem eigenen Service liegt, kann diese auch jederzeit programmatisch auf einen beliebigen Payload angewendet werden. Dies kann hilfreich sein, wenn zum Beispiel eine Datei gegeben ist, welche entsprechende MultiPart-Daten enthält.