In my overview article on Liferay Q2 2026, I mentioned the new headless CMS as one of three strategic directions—and then moved on from it relatively quickly because Digital Sales Rooms and the cloud topic took up a lot of space. That was fair for an overview, but it didn’t 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 customer base. No beta features, no enterprise subscriptions, no AWS contract required. Anyone who uses Liferay for content work will notice these improvements immediately.
There are four topics I want to break down here: editable content structures, referenceable entries, bulk search & replace, and the switch to CKEditor 5 as the default editor. Taken individually, each is a meaningful improvement. Together, they tell a story about where Liferay wants to take the CMS.
Editing structures retroactively: Finally.
Anyone who has created content structures in Liferay and, after some time, realized that the original plan no longer fits reality is familiar with the problem: renaming a field, introducing a new group, reordering fields—all of this was possible as long as no content was linked to them yet. As soon as the first articles, products, or pages were based on a structure, any 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 reimport everything. Not a pleasant process.
With Liferay 2026 Q2, that’s a thing of the past. Content structures can now be edited retroactively without having to delete or migrate existing entries. Fields can be added, reordered, and configured. Content that has already been published remains intact. This may sound like a technical given, but it was a real limitation that influenced decisions in many projects. Teams designed structures much more generously than necessary from the start, just to avoid having to make changes later. This defensive approach can now change because a safety net is in place.
For administrators and content architects, this is one of the most significant innovations in a long time. Content models can now be developed iteratively, just as content requirements evolve in real-world operations.
Referenceable Entries: From Document to Data Network
The second major CMS feature in Q2 2026 is more subtle, but at least as significant in its scope: content entries can now reference other entries instead of retyping information over and over 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 a different object—either a single entry or multiple entries, as the use case requires. When filling in the field, content creators then select the corresponding entry from a list.
A real-world example makes this clearer: A company maintains a product catalog and a knowledge base. Previously, authors who referenced 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 links directly to the product entry. If the product name changes, the update is reflected everywhere.
For teams managing larger content repositories, this fundamentally changes maintenance work. Author names, categories, locations, product references, vendor data—all of this can now be managed centrally and referenced everywhere. Update once, consistent everywhere.
From a slightly more technical perspective, this marks the shift from a document-centric CMS to a true content graph. Content is no longer isolated documents, but connected data points within a shared model. This foundation makes many advanced use cases possible.
Bulk Search & Replace: The Feature Content Teams Deserve
There are features that receive immediate applause upon their announcement because everyone instantly understands why they were needed. Bulk Search & Replace is one such feature.
Content teams can now search across the entire platform for text, URLs, or terms and replace them in a single step. Across all pages, all content types, all fields. With a mandatory preview before the commit is executed, with automatic versioning, and with the ability to roll back if necessary.
Anyone who has ever coordinated a corporate rebranding across a medium-sized Liferay instance knows what this means. Replacing the old company name with the new one. Replacing the old domain with the new one. Updating outdated product names. Until now, this was manual work—or a database intervention that was impossible to perform without deep technical knowledge and always posed a risk.
Now it’s 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 kind of feature that tangibly improves the day-to-day work of content teams without requiring a single line of code to be written.
CKEditor 5 as the Standard: 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 is technically outdated: HTML5 support was patchy, modern browser APIs were underutilized, and the architecture imposed limitations that increasingly conflicted with Liferay’s modern frontend stack. CKEditor 5 is built from the ground up, significantly more modern, and offers a much better foundation for future extensions.
The transition isn’t entirely painless. Anyone who has developed custom plugins based on CKEditor 4—and many Liferay projects have done so over the years—faces a migration task. CK4 plugins don’t simply run on CK5. The architectures are fundamentally different.
Liferay has built in a solution for this scenario: a feature flag reactivates CKEditor 4 as a temporary fallback, so projects don’t have to act overnight. But this is a stopgap, 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’s the majority—the switch is straightforward and brings a noticeable improvement in quality when using the rich-text editor on a daily basis.
A side note: CKEditor 4 remains the standard for features in so-called maintenance mode, namely blogs and the knowledge base. These features will not be migrated to CK5. Anyone who uses these areas extensively should keep this in mind.
What these four features mean together
Viewed individually, Editable Structures, Reference Fields, Bulk Replace, and CKEditor 5 are each meaningful, well-founded improvements. Together, they tell a clear story.
Liferay is expanding the Headless CMS into a platform that can keep pace with the demands of real-world production use. Not just during initial setup, but during ongoing operations, when content models change, content volumes grow, and requirements shift.
This is an important step. Enterprise CMS systems are often evaluated based on how well they perform at launch. The truly critical question, however, is how well they perform 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 precisely this question a bit better.
For customers currently using Liferay: It’s worth going through these features with your own team and considering which of your previous workarounds can now be eliminated.
We at Portalworks are happy to help you assess and implement this for your specific situation—whether that’s a workshop on content model revision, the CKEditor migration, or simply a discussion about what makes sense and what can wait.
Next week in this series, we’ll take a look at Digital Sales Rooms—the beta feature that’s taking Liferay into new territory.
