In the overview article on Liferay 2026 Q2, I mentioned the new headless CMS as one of three strategic course-settings – and then moved on from it relatively quickly, because Digital Sales Rooms and the cloud topic demanded a lot of space. That was fair for an overview, but it did not quite do the CMS justice.
Because if you take a closer look at the features of this release, the CMS area is the part that brings the most concrete changes for the broadest possible range of customers. No beta features, no enterprise subscriptions, no AWS contract required. If you use Liferay for content work, you will encounter these improvements immediately.
There are four topics I want to unpack here: editable content structures, referenceable entries, bulk search & replace, and the switch to CKEditor 5 as the default editor. Taken individually, each of them is a sensible improvement. Together, they tell a story about where Liferay wants to take the CMS.
Editing structures after the fact: Finally.
If you have created content structures in Liferay and realized after a while that the original plan no longer matches reality, you know the problem: renaming a field, introducing a new group, reworking the order of the fields – all of this was possible as long as no content was linked to it yet. As soon as the first articles, products or pages were based on a structure, every structural change became risky or even impossible.
In practice, this led to a well-known pattern: freeze the structure, live with the compromises, or, for truly urgent changes, export everything, delete the structure, rebuild it and re-import everything. Not a pleasant process.
With Liferay 2026 Q2, that is over. Content structures can now be edited after the fact without having to delete or migrate existing entries. Fields can be added, reordered and configured. Content that has already been published remains intact. That sounds like a technical matter of course, but it was a real limitation that influenced decisions in many projects. Teams created structures much more generously than necessary from the outset, just to avoid later changes. This defensive behavior can now change, because the safety net is there.
For administrators and content architects, this is one of the more relevant innovations in a long time. Content models can now be developed iteratively, just as content requirements evolve in real-world operation.
Referenceable Entries: From document to data network
The second major CMS feature in 2026 Q2 is more subtle, but at least as significant in its scope: content entries can now reference other entries instead of information being typed in again and again.
Specifically, this works via new “Link Content Fields”. A data model creator defines a field that does not point to a text value but to another entry in another object. Single or multiple, as the use case requires. Content creators then select the corresponding entry from a list when filling in the field.
A practical example makes this more tangible: a company maintains a product catalog and a knowledge base. Until now, authors who referred to a product in a knowledge base article had to type in the product name. If the product name changed, all articles had to be updated manually, or they simply contained the wrong name. With reference fields, the knowledge base article now points directly to the product entry. If the product name changes, the change is carried over everywhere.
For teams that run larger content repositories, this fundamentally changes maintenance work. Author names, categories, locations, product references, vendor data – all of this can now be maintained centrally and referenced everywhere. Update once, consistent everywhere.
From a somewhat more technical perspective, this is the step from a document-centric CMS toward a true content graph. Content is no longer a set of isolated documents but connected data points in a shared model. This is a foundation that makes many further use cases possible in the first place.
Bulk Search & Replace: The feature content teams deserve
There are features that receive applause immediately after their announcement, because everyone instantly understands why they were needed. Bulk search & replace is such a feature.
Content teams can now search for text, URLs or terms across the entire platform and replace them in one step. Across all pages, all content types, all fields. With a mandatory preview before the commit is carried out, with automatic versioning, and with the option to roll back if necessary.
If you have ever coordinated a corporate rebranding across a medium-sized Liferay instance, you know what this means. Replace the old company name with the new one. The old domain with the new one. Update outdated product names. Until now, this was manual work – or a database intervention that could not be carried out without deep technical knowledge and always posed a risk.
Now it is an editorial operation with a clear preview and a defined way back. Scope targeting is also possible: the replacement can be limited to a specific site, a content type or a specific field. If you want to work globally, you can. If you want to proceed surgically, you can do that too.
This is the type of feature that concretely improves the everyday work of content teams, without a single line of code having to be written for it.
CKEditor 5 as the default: A modernization that comes at a price
CKEditor 4 is deprecated. CKEditor 5 is now the default editor in Liferay DXP.
This is a decision that was long overdue. CKEditor 4 has aged considerably from a technical standpoint: HTML5 support was patchy, modern browser APIs were used only inadequately, and the architecture imposed limits that increasingly conflicted with Liferay's modern frontend stack. CKEditor 5 has been rebuilt from the ground up, is significantly more modern, and offers a much better starting point for future extensions.
The transition is not entirely painless. If you have developed custom plugins based on CKEditor 4 – and many Liferay projects have done so over the years – you are facing a migration task. CK4 plugins do not simply run on CK5. The architectures are fundamentally different.
Liferay has built in a solution for this case: a feature flag reactivates CKEditor 4 as a temporary fallback, so projects do not have to act overnight. But this is a bridge, not a permanent solution. The direction is clear, and projects with CK4 custom plugins should put the migration on their medium-term roadmap.
For everyone else – and that is the majority – the switch is straightforward and a noticeable gain in quality when working with the rich text editor every day.
A side note: CKEditor 4 remains the default in features that are in so-called maintenance mode, i.e. Blogs and the Knowledge Base. These features will not be migrated to CK5. If you use these areas intensively, you should keep this in mind.
What these four features mean together
Taken individually, editable structures, reference fields, bulk replace and CKEditor 5 are each sensible, well-founded improvements. Together, they tell a clear story.
Liferay is expanding the headless CMS into a platform that can keep up with the demands of real production use. Not only during the initial setup, but in ongoing operation, when content models change, content volumes grow, and requirements shift.
This is an important step. Enterprise CMS systems are often judged by how well they work at launch. The truly decisive question, however, is how well they work when the project is three years old, the content model has been revised ten times, and the team has changed. With this release, Liferay answers exactly this question somewhat better.
For customers running Liferay today: it is worth going through these features with your own team and considering which of your previous workarounds they make obsolete.
At Portalworks, we are happy to help you assess and implement this for your specific situation – whether that is a workshop on revising your content model, the CKEditor migration, or simply a conversation about what makes sense and what can wait.
Next week, this series continues with a look at Digital Sales Rooms – the beta feature that takes Liferay into new territory.
