Die KI-Schicht: Pragmatisch statt visionär – und das ist das Lob
Viele CMS-Anbieter haben im letzten Jahr KI als Marketinglabel oben drauf geklebt. Magnolia geht einen anderen Weg: Die KI-Features in 6.4 sind konsequent in bestehende Workflows eingebettet, ohne sie zu zerreißen.
Das prominenteste Beispiel ist der integrierte KI-Bildeditor im DAM. Autoren können direkt in Magnolia Seitenverhältnisse ändern, Hintergründe entfernen, Elemente hinzufügen oder löschen – ohne einen externen Editor zu öffnen. Was wie ein komfortables Feature klingt, hat eine strategische Konsequenz: Der Kontext-Switch, der in der Praxis regelmäßig zu Versionierungsproblemen und Schatten-Assets führt, entfällt. Das Asset lebt, versioniert und genehmigt, in einem System.
Bemerkenswert ist die Entscheidung beim Image Recognition Module: Statt wie bisher AWS Rekognition fest zu verdrahten, ist das Modul nun LLM-agnostisch. Jedes multimodale Modell kann angebunden werden – ob OpenAI, Google Gemini, Azure AI Vision oder ein selbst gehostetes Open-Source-Modell. Für Unternehmen mit bestehenden KI-Verträgen oder Datenschutzanforderungen ist das kein Detail, sondern ein Freischein.
Die automatische Metadaten-Befüllung (Title, Description, Alt-Text) rundet das Bild ab. Triggern lässt sie sich manuell, als Bulk-Aktion oder vollautomatisch bei Upload. Mehrsprachig. Das klingt klein, ist in der Praxis aber einer der teuersten Handarbeitsprozesse in Content-Teams – SEO-konforme Alt-Texte für 50.000 DAM-Assets waren bisher ein Beratungsauftrag. Ab 6.4 ist es eine Schaltfläche.
Swift Publication: Das stille Architekturproblem wird gelöst
Wer jemals in einem Multi-Cluster-Magnolia-Setup gearbeitet hat, kennt den Schmerz: Eine große Publikation blockiert, Autoren warten, das System atmet schwer. Das ist kein Bug, das ist die Architektur des bisherigen JCR-basierten Publikationsmodells – synchron, sperrlastig, und linear in einem System, das für parallele Enterprise-Workloads gebaut sein soll.
Swift Publication ist die Antwort, und sie ist architektonisch konsequent. Der neue, asynchrone Engine trennt den Publikationsvorgang vom Autorenwerkzeug: Änderungen werden an einen externen Version Store (S3 oder Azure Blob Storage) geschickt und über einen Message Broker verteilt. Autoren arbeiten weiter, während im Hintergrund publiziert wird. Das Ergebnis laut Magnolia: über 70 % schnellere Publikation in komplexen Multi-Cluster-Setups.
Der Haken ist transparent kommuniziert: Swift Publication ist ein separates Enterprise-Modul, das zusätzliche Infrastruktur voraussetzt – einen externen Version Store und einen Message Broker. PaaS-Kunden bekommen das out of the box; On-Premises-Betreiber müssen die Infrastruktur selbst provisionieren. Das ist kein Verstecken von Komplexität, sondern eine ehrliche Trennung: Wer die Performance will, trägt die Infrastrukturverantwortung. Für moderne Cloud-Setups ist das kein Problem. Für klassische On-Premises-Installationen in Konzernen mit starren Infrastrukturprozessen wird das eine Diskussion.
Jakarta EE 10: Die Migration, auf die alle gewartet haben
Magnolia läuft ab 6.4 auf Jakarta EE 10 als Baseline – und damit auf Tomcat 10+, modernen Servlet-Containern, und einem Java-Ökosystem, das den javax-Namensraum endlich hinter sich gelassen hat. Wer in den letzten Jahren Custom-Module für Magnolia entwickelt hat, weiß, wie viel latenter Schmerz in der javax vs. jakarta-Paketnamensfrage steckt.
Praktisch bedeutet das: Neue Integrationen mit modernen Frameworks, Libraries und Containern sind ohne Namespace-Shims möglich. Security-Updates für die EE-Schicht kommen aus einem aktiven Upstream. Und Deployment auf Container-Infrastruktur, die EE9+ voraussetzt, funktioniert ohne Workarounds.
Für bestehende Custom-Module bedeutet das eine Migration – aber eine planbare. Magnolia hat die EE9-Kompatibilitätspfade seit 6.3 vorbereitet, 6.4 schließt den Schritt ab.
WCAG 2.1 AA: Compliance als Feature, nicht als Pflicht
Das neue UI-Framework in 6.4 – schrittweise Ablösung der Vaadin-Formulare durch eigene Komponenten – bringt neben Performance auch WCAG 2.1 AA-Konformität im Authoring-Interface selbst. Verbesserte Fokus-Sichtbarkeit, vollständige Tastaturnavigation, saubere semantische Struktur. Die Vorbereitung auf WCAG 2.2 ist bereits eingebaut.
Das klingt nach einem Thema für Accessibility-Spezialisten. Es ist aber zunehmend ein Beschaffungskriterium: Öffentliche Auftraggeber und regulierte Branchen in der EU verlangen WCAG-Konformität nicht nur für die publizierten Websites, sondern zunehmend auch für die eingesetzten internen Systeme.
Einordnung: Wo steht Magnolia 2026?
Im Gartner Magic Quadrant für Digital Experience Platforms hat Magnolia 2025 zum fünften Mal in Folge die Position als Visionary gehalten. Das ist weniger aufregend als ein Sprung in den Leaders-Quadrant – aber auch ehrlicher. Magnolia ist kein Salesforce Experience Cloud-Konkurrent. Die Stärke liegt in der Komposabilität: eine stabile, erweiterbare Plattform, die sich in komplexe Enterprise-Stacks integriert, ohne alles selbst sein zu wollen.
Version 6.4 macht dieses Versprechen glaubwürdiger. Die KI-Features sind keine Decorations, sondern eingebettet in reale Authoring-Workflows. Swift Publication löst ein echtes Skalierungsproblem. Jakarta EE 10 schließt technische Schulden ab. Und die WCAG-Arbeit antizipiert regulatorische Anforderungen, bevor sie brennend werden.
Für Magnolia-Projekte in der Planung oder im laufenden Betrieb bedeutet 6.4 konkret: Der Upgrade-Pfad ist klarer als bei vielen Vorgängerreleases, die Infrastrukturanforderungen für Swift Publication sollten frühzeitig bewertet werden, und die LLM-Freiheit beim Image Recognition Module gibt Spielraum, den man nutzen sollte – besonders wenn bereits KI-Infrastruktur im Unternehmen besteht.
Portalworks begleitet Magnolia-Projekte von der Architekturentscheidung bis zum laufenden Betrieb. Fragen zur Bewertung von 6.4 für euren spezifischen Stack? Sprecht uns an.
