Im Überblicksartikel zu Liferay 2026 Q2 habe ich den neuen Headless CMS als eine von drei strategischen Weichenstellungen erwähnt – und ihn dann relativ schnell wieder verlassen, weil Digital Sales Rooms und das Cloud-Thema viel Platz gefordert haben. Das war fair für einen Überblick, aber dem CMS gegenüber nicht ganz gerecht.
Denn wenn man sich die Features dieses Release genauer ansieht, dann ist der CMS-Bereich der Teil, der für den breitest möglichen Kundenkreis die konkretesten Änderungen mitbringt. Keine Beta-Features, keine Enterprise-Subscriptions, kein AWS-Vertrag nötig. Wer Liferay für Content-Arbeit nutzt, trifft diese Verbesserungen sofort.
Vier Themen sind es, die ich hier auseinanderfalten will: editierbare Content-Strukturen, referenzierbare Einträge, Bulk Search & Replace, und der Wechsel zu CKEditor 5 als Standardeditor. Einzeln betrachtet ist jedes davon eine sinnvolle Verbesserung. Zusammen erzählen sie eine Geschichte darüber, wohin Liferay den CMS führen will.
Strukturen nachträglich bearbeiten: Endlich.
Wer in Liferay Content-Strukturen angelegt hat und nach einiger Zeit feststellt, dass die ursprüngliche Planung nicht mehr zur Realität passt, kennt das Problem: Ein Feld umbenennen, eine neue Gruppe einführen, die Reihenfolge der Felder überarbeiten – alles war möglich, solange noch keine Inhalte damit verknüpft waren. Sobald die ersten Artikel, Produkte oder Seiten auf einer Struktur basierten, wurde jede strukturelle Änderung riskant bis unmöglich.
Das hat in der Praxis zu einem gut bekannten Muster geführt: Struktur einfrieren, mit den Kompromissen leben, oder bei wirklich dringenden Änderungen alles exportieren, die Struktur löschen, neu aufbauen, alles neu importieren. Kein schöner Prozess.
Mit Liferay 2026 Q2 ist das vorbei. Content-Strukturen können jetzt nachträglich bearbeitet werden, ohne dass bestehende Einträge gelöscht oder migriert werden müssen. Felder können hinzugefügt, umsortiert und konfiguriert werden. Die bereits publizierten Inhalte bleiben intakt. Das klingt nach einer technischen Selbstverständlichkeit, war aber eine echte Einschränkung, die in vielen Projekten Entscheidungen beeinflusst hat. Teams haben Strukturen von Anfang an deutlich großzügiger angelegt, als nötig, nur um spätere Änderungen zu vermeiden. Dieses defensive Verhalten wird sich jetzt ändern können, weil das Sicherheitsnetz vorhanden ist.
Für Administratoren und Content-Architekten ist das eine der relevanteren Neuerungen seit langem. Inhaltsmodelle können jetzt iterativ weiterentwickelt werden, so wie sich auch die inhaltlichen Anforderungen im echten Betrieb weiterentwickeln.
Referenceable Entries: Vom Dokument zum Datennetz
Das zweite große CMS-Feature in 2026 Q2 ist subtiler, aber in seiner Tragweite mindestens genauso bedeutsam: Content-Einträge können jetzt andere Einträge referenzieren, statt Informationen immer wieder neu einzutippen.
Konkret funktioniert das über neue "Link Content Fields". Ein Datenmodell-Ersteller definiert ein Feld, das nicht auf einen Text-Wert zeigt, sondern auf einen anderen Eintrag in einem anderen Objekt. Einzeln oder mehrfach, wie es der Anwendungsfall erfordert. Content-Ersteller wählen dann beim Befüllen des Felds den entsprechenden Eintrag aus einer Liste aus.
Ein Beispiel aus der Praxis macht das greifbarer: Ein Unternehmen pflegt einen Produktkatalog und eine Wissensdatenbank. Bisher mussten Autoren, die in einem Wissensdatenbankartikel auf ein Produkt verwiesen, den Produktnamen eintippen. Änderte sich der Produktname, mussten alle Artikel manuell aktualisiert werden, oder sie enthielten schlicht den falschen Namen. Mit Reference Fields zeigt der Wissensdatenbankartikel jetzt direkt auf den Produkteintrag. Ändert sich der Produktname, zieht die Änderung überall mit.
Für Teams, die größere Content-Repositories betreiben, verändert das die Wartungsarbeit grundlegend. Autorennamen, Kategorien, Standorte, Produktreferenzen, Anbieterdaten – all das kann jetzt zentral gepflegt und überall referenziert werden. Einmal aktualisieren, überall konsistent.
Aus einer etwas technischeren Perspektive ist das der Schritt von einem dokumentenzentrierten CMS hin zu einem echten Content-Graph. Inhalte sind nicht mehr isolierte Dokumente, sondern verbundene Datenpunkte in einem gemeinsamen Modell. Das ist eine Grundlage, die viele weiterführende Anwendungsfälle erst möglich macht.
Bulk Search & Replace: Der Artikel, den Content-Teams verdient haben
Es gibt Features, die nach ihrer Ankündigung sofort Beifall bekommen, weil jeder sofort versteht, warum sie gebraucht wurden. Bulk Search & Replace ist so ein Feature.
Content-Teams können jetzt plattformweit nach Text, URLs oder Begriffen suchen und diese in einem Schritt ersetzen. Über alle Seiten, alle Inhaltstypen, alle Felder. Mit einer verpflichtenden Vorschau bevor der Commit durchgeführt wird, mit automatischer Versionierung, und mit der Möglichkeit, bei Bedarf zurückzurollen.
Wer schon mal ein Unternehmens-Rebranding über eine mittelgroße Liferay-Instanz koordiniert hat, weiß, was das bedeutet. Alter Unternehmensname gegen neuen ersetzen. Alte Domain gegen neue. Veraltete Produktbezeichnungen aktualisieren. Das war bisher Handarbeit – oder ein Datenbankeingriff, der ohne tiefes technisches Wissen nicht durchführbar war und immer ein Risiko darstellte.
Jetzt ist das eine redaktionelle Operation mit einer klaren Vorschau und einem definierten Rückweg. Scope-Targeting ist ebenfalls möglich: Die Ersetzung kann auf einen bestimmten Site, einen Inhaltstyp oder ein bestimmtes Feld begrenzt werden. Wer global arbeiten will, kann das. Wer chirurgisch vorgehen will, kann das auch.
Das ist der Typ von Feature, der den Alltag von Content-Teams konkret verbessert, ohne dass dafür eine einzige Zeile Code geschrieben werden muss.
CKEditor 5 als Standard: Eine Modernisierung, die ihren Preis hat
CKEditor 4 ist deprecated. CKEditor 5 ist ab sofort der Standard-Editor in Liferay DXP.
Das ist eine Entscheidung, die schon länger kommen musste. CKEditor 4 ist technisch weit in die Jahre gekommen: HTML5-Support war lückenhaft, moderne Browser-APIs wurden nur unzureichend genutzt, und die Architektur hat Grenzen gesetzt, die mit Liferays modernem Frontend-Stack zunehmend in Konflikt geraten sind. CKEditor 5 ist von Grund auf neu gebaut, deutlich moderner, und bietet eine wesentlich bessere Ausgangslage für zukünftige Erweiterungen.
Die Transition ist nicht völlig schmerzlos. Wer Custom-Plugins auf Basis von CKEditor 4 entwickelt hat – und das haben viele Liferay-Projekte im Laufe der Jahre getan – steht vor einer Migrationsaufgabe. CK4-Plugins laufen nicht einfach auf CK5. Die Architekturen sind fundamental verschieden.
Liferay hat für diesen Fall eine Lösung eingebaut: Eine Feature Flag reaktiviert CKEditor 4 als temporären Fallback, sodass Projekte nicht von heute auf morgen handeln müssen. Aber das ist eine Brücke, keine dauerhafte Lösung. Die Richtung ist klar, und Projekte mit CK4-Custom-Plugins sollten die Migration auf ihre mittelfristige Roadmap setzen.
Für alle anderen – und das ist die Mehrheit – ist der Wechsel unkompliziert und ein spürbarer Qualitätsgewinn im täglichen Umgang mit dem Rich-Text-Editor.
Ein Detail am Rande: CKEditor 4 bleibt der Standard in Features, die sich im sogenannten Maintenance Mode befinden, also Blogs und die Knowledge Base. Diese Features werden nicht auf CK5 migriert. Wer diese Bereiche intensiv nutzt, sollte das im Kopf behalten.
Was diese vier Features zusammen bedeuten
Einzeln betrachtet sind editable Structures, Reference Fields, Bulk Replace und CKEditor 5 jeweils sinnvolle, gut begründete Verbesserungen. Zusammen erzählen sie eine klare Geschichte.
Liferay baut den Headless CMS zu einer Plattform aus, die mit den Anforderungen eines echten produktiven Einsatzes mithalten kann. Nicht nur beim ersten Aufsetzen, sondern im laufenden Betrieb, wenn Inhaltsmodelle sich verändern, Inhaltsvolumina wachsen, und Anforderungen sich verschieben.
Das ist ein wichtiger Schritt. Enterprise-CMS-Systeme werden häufig danach bewertet, wie gut sie beim Start funktionieren. Die wirklich entscheidende Frage ist aber, wie gut sie funktionieren, wenn das Projekt drei Jahre alt ist, das Inhaltsmodell zehnmal überarbeitet wurde, und das Team gewechselt hat. Genau diese Frage beantwortet Liferay mit diesem Release ein stück weit besser.
Für Kunden, die Liferay heute betreiben: Es lohnt sich, diese Features mit dem eigenen Team durchzugehen und zu überlegen, welche der bisherigen Workarounds sich damit erledigen.
Wir bei Portalworks helfen gern dabei, das für eure konkrete Situation einzuordnen und umzusetzen – ob das ein Workshop zur Inhaltsmodell-Überarbeitung ist, die CKEditor-Migration, oder einfach nur ein Gespräch darüber, was sinnvoll ist und was warten kann.
In der nächsten Woche folgt in dieser Serie der Blick auf Digital Sales Rooms – das Beta-Feature, das Liferay in ein neues Terrain führt.
