Get the MOST

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.

Gegenwärtig laufen die Arbeiten an der nächsten Symfony-Version 6.1. Wie immer gibt es regelmäßige Einblicke in die wichtigsten, zu erwartenden Features und Verbesserungen. Dieser Beitrag zeigt im Folgenden die bisher veröffentlichten Blog-Beiträge thematisch nach Komponente sortiert.

Allgemein

Verbesserungen bzgl. Typisierung

Diverse Verbesserungen

Console

Verbesserte Autovervollständigung

DependencyInjection

Service Decoration Attribute

Service Autowiring Attribute

Expressions als Service Factories

ExpressionLanguage

Verbesserungen an der Syntax

Form

Anpassbare Prototypen für Collections

HtmlSanitizer

Neue HtmlSanitizer-Komponente

HttpKernel

Controller argument resolver für Enums

Einfachere Bundle-Erweiterung und -Konfiguration

Messenger

Notifier- und Messenger-Integrationen

Mime

Draft E-Mails

Notifier

Notifier- und Messenger-Integrationen

Profiler

Profiler-Verbesserungen (Teil 1)

Profiler-Verbesserungen (Teil 2)

Routing

Verbesserte Routing-Requirements und UTF-8 Parameter

Services in Route-Bedingungen

Semaphore

Konfigurierbare Semaphoren

Serializer

Serializer Context Builders

Serializer Profiling

Translation

Locale-Switcher

Am 21. April erscheint die nächste Ubuntu-Version Jammy Jellyfish mit LTS (Long Time Support), die 5 Jahre lang mit Updates versorgt werden wird. Üblicherweise aktualisiere ich unsere Rechner schon drei, vier Wochen vor dem finalen Release und so habe ich eben auch den Sprung von 21.10 auf 22.04 gewagt. Konkret ging es um fünf Installationen von Kubuntu auf auf unterschiedlichen Notebooks von Dell und Lenovo sowie einem Desktop-Rechner. Im Folgenden wird das ein oder andere Stolpersteinchen beschrieben, wobei es ja auch noch knapp einen Monat Zeit ist, bis das letztendliche Release erscheint.

Shopware 6 bietet per Standard zwei Möglichkeiten, wie mit Varianten eines Produktes in der Listenansicht umgegangen werden soll: entweder es wird eine bestimmte Hauptvariante angezeigt oder aber die Varianten werden anhand einer Produkteigenschaft aufgefächert. Das heißt, man sieht dann z. B. alle Farben eines T-Shirts einzeln, als wären es eigenständige Produkte.

Für ein Projekt hatten wir nun die Anforderung, dass alle Varianten dargestellt, jedoch in einem gemeinsamen Block kombiniert werden sollen. In der Detailansicht kann man zwischen den Varianten umschalten, wie man es etwa von Amazon kennt. Genau diese Funktionalität bietet das handliche Plugin shopware-variant-switch/ - definitiv einen Tipp wert 😄