This release introduces in-context translation for all the form fields directly within the page editor. This empowers content creators to easily create localized form experiences for their users, enabling them to complete forms in their preferred language. Only designated localizable form fields will be translated, ensuring precise control over localized content.

Key Benefits:

• Faster time to publish localized forms: Translating directly in the editor reduces the steps needed to launch forms in multiple languages.

• Reduces reliance on external tools or workflows: Content teams can manage translations within the same interface they use to build pages, simplifying the process.

• Improves accuracy and consistency: Only the form fields marked as translatable are included, so there's less risk of translating the wrong content or missing something important.

• Better experience for global audiences: Visitors can complete forms in their preferred language, which can increase completion rates and engagement.Gives teams more control over localization: Editors can choose exactly what gets translated and when, without needing developer support.

Field visibility can now be configured based on values within the same custom fragment. This enables fields to dynamically show or hide based on user input, supporting more responsive and context-aware interfaces.

This update gives teams more flexibility when building custom fragments, making it easier to support complex use cases without additional custom code.

Customers very commonly deploy fragments through the deploy folder, we identified that we are missing one log once the fragment import finished. Until now Liferay added a message in the application server logs that show that the fragment import has started, but it never indicates when it finishes. Some advantages of logging when the import process finishes is that customers can check when the deployment is still in progress and when it ends, not only being informed in case of failures.

This feature enable the creation of multi steps forms in Page Editor.

Allow users to modify only the first collection display item.

The existing documentation for Clay components and the API Table has been inconsistent in quality, often lacking detailed explanations and practical examples. This inconsistency makes it difficult for developers to effectively utilise these components, leading to confusion and an increased number of support requests.

Key Benefits:

• Developers now have a better mechanism for generating API Tables for components, improving the overall understanding of component usage and available APIs. With detailed explanations and real-world examples.

• With this new standardised documentation practices we can ensure a uniform quality and completeness across all components.

• Clearer, more structured, and more practical documentation will reduce frustration and improve the development process.

• Clearer documentation minimizes the need for external support, freeing up resources and improving response times.

We integrated the Clay Table's column visibility dropdown and column sorting functionalities into the Frontend Data Set. This makes a unified approach to table interactions across Liferay, replacing inconsistent custom implementations.

Key Benefits:

• A more standard column visibility and sorting that guarantee a more usable and predictable interaction across the platform.

• Reduces redundant code by aligning with the Clay Table’s native functionalities.

• Developers no longer need to manage multiple implementations for similar features.

• Ensures UI and UX consistency with Liferay’s design system.

Style Books in Liferay are now explicitly tied to a specific theme at the moment of creation, using the frontend token definition provided by that theme (via OSGi or themeCSS client extension). This structural link now ensures that each Style Book can only operate within the boundaries of its associated theme, eliminating cross-theme token contamination and enforcing clearer theme-based design governance.

Key Benefits:

• Users can no longer save Style Books that accidentally combine tokens from different themes, avoiding visual inconsistencies and design regressions.

• Every Style Book now visibly shows which theme it belongs to, reducing errors and making it easier for teams to manage design assets across multiple sites.

• When applying a Style Book to a page, the system will only list those created with the same theme as the page’s current one—no more trial-and-error or guesswork.

• If a Style Book becomes incompatible with the applied theme (e.g., after a theme change), it will be automatically unlinked to prevent display issues.

• During platform upgrades, existing Style Books are automatically linked to the site’s current public theme (as defined in Site Builder > Pages > Options > Configuration), reducing manual cleanup work.

• If a Style Book is imported without a valid themeId, the user gets a clear warning and knows exactly what’s missing to fix the import.

• Style Books based on themes that are no longer deployed or no longer provide a valid frontend token definition are automatically marked as inactive—clearly flagged and non-selectable.

• The OSGi or themeCSS client extension ID is displayed for inactive Style Books, helping devs or admins identify which theme needs to be re-installed or fixed.

With the release of Liferay DXP 2025.Q2, we are deprecating the Elasticsearch 7 compatibility due to the end-of-maintenance and upcoming EOL of the Elastic Stack 7.17. Liferay strongly recommends all customers with 7.17.x or earlier deployments to upgrade to the latest compatible version of Elasticsearch 8.x. Learn more. 

The Concurrent and Sync Reindex Modes, providing high-availability, introduced in Liferay DXP 7.4 Update 98 / Liferay DXP 2023.Q4 are now GA.

Reduce downtime, improve operational and resource utilization efficiency with the new Concurrent and Sync reindex execution modes providing high-availability in search capabilities while the operation is running.

In this release a new type of Data Set called System Data Sets is introduced, which will allow admin users to clone Java/Code Data Sets, making them editable and customizable through the Data Set Manager, which allow to customize any administration part of DXP built with a customizable Java/Code Data Set.

In this release the Data Sets from Order Pages have been made available as System Data Sets:

• Pending Order Items

• Placed Order Items

• Order Returns

• Pending Orders

• Placed Orders

In the next releases more and more Data Sets will be added to the list.
 

Key Benefits

• This epic increases the flexibility of Liferay DXP by enabling partial customization of previously hardcoded Data Sets.

• Admins will have more control over the user experience, enhancing the platform's ability to meet diverse and evolving business requirements.

• This also reduces the need for custom development efforts to modify or replace hardcoded Data Sets.

When an admin user is managing a Data Set, they might create sorting options, filters and actions. Until now, if the admin user chose not to show them to the end-user, they had to be deleted. From now on, these sub-entities can be deactivated, hiding them from the end-user without losing editing progress.

Key Benefits:

• Easier management of sub-entities without requiring deletion and recreation.
• Improved usability by allowing admins to configure visibility dynamically.
• More flexibility in defining experiences without modifying underlying data.

Improved the usability, functionality, and consistency of bulk actions in Frontend Data Sets across Liferay DXP. The selection behaviour of items has been refined, ensuring consistency in visualization modes, enhancing bulk action visibility, and making interactions more intuitive and efficient for end users.

Key Benefits:

• Preserve selection between pages of items so the user can easily select items from multiple pages.
• Add Select All and Clear buttons to allow users to easily work with large amount of items.
• Added contextual menu with access to all bulk actions available.
• Highlighted bulk actions to easily access more common actions.

As customers increasingly adopt HTML5 for content creation, there's a growing need to upgrade the current rich text editing capabilities and CKEditor 5 has been selected as the default editor for Liferay DXP to meet this demand. In this release CK Editor 5 has been made available in DXP and installed in four different experiences under Beta Feature Flag. (FF-11235):

• Web Content

• Object entry (editing a Rich Text Field)

• Document Types (when adding a Rich Text field)

• Metadata Set (when adding a Rich Text field)

• Forms

• Element Sets

After this, CK Editor 5 will be included in other areas and experiences in the near future:

• Page Builder

• Commerce

• Web Content Description

Key Benefits:

Benefits when CK Editor is available across all DXP, note that current effort only includes Webcontent

1. Support modern web standards, including HTML5 and Content Security Policy (CSP).

2. Provide a seamless copy-paste experience from external tools.

3. Leverage OOTB features like the inline editor for a more flexible editing workflow.

4. Adopt a supported and actively maintained version of CK Editor.

5. Remove reliance on multiple editors and standardize the editing experience across Liferay DXP.

More highlights and benefits here

To continue broading the CSP support now 2 new directives are supported: base-uri and object-src

With these two new directives support Liferay DXP covers all the directives recommended in the Google CSP Evaluator.

Key Benefits:

• Enhanced Security: Mitigates risks of XSS and data injection attacks by controlling resource loading and execution.

• Compliance-Friendly: Aligns with industry-standard security requirements, supporting stricter compliance protocols.

• Customizable Policies: Allows developers to tailor CSP directives to meet specific project or organizational needs.

• Improved Trust: Strengthens end-user trust by providing a more secure and reliable platform experience.

Supported directives with recommended values:

Working with Global Services to identify pain points in Javascript resources distribution and unused code was the trigger to:

• Remove unused packages

• Deprecate old packages

• Set configurations to let users to not use/load some functionalities

• Create a JS size comparision report

• Create tooling to be able to split modules in smaller submodules
   

Key Benefits:

• Reduced total JS bundle size → Faster portal loading

• Reduced total exports → Faster portal loading

• Taking as example Masterclass home page:

  • Reduced JS Size in MB by 20%

  • Reduced number of request by 12 %

  • Mobile Lighthouse score from 52 to 56

  • Desktop Lighthouse score from 70 to 77

• Allow teams to divide modules to offer smaller entry points when they detect some part of the module is not commonly used.

• Size report tooling able to trigger risks.

The Lodash library is being deprecated and it is not included in the bundle unless deprecation FF LPD-48975 is enabled.

The AMD Loader is being deprecated and it is not included in the bundle unless deprecation FF LPD-48372 is enabled.

As a result of the AMD Loader deprecation, the npm-bundler will stop working too, it is recommended to use standard bundling tools such as webpack, esbuild, vite, etc.

The JS Component Support Tabs (data-toggle="liferay-tabs" API ) is being deprecated and it is not included in the bundle unless deprecation FF LPD-47713 is enabled.

DXP is now certified for use with the MySQL 8.4 database version. Also applies to 2025.Q1 LTS.

Key Benefits:

Allows users to update to the latest LTS version of MySQL database. As an LTS release, MySQL 8.4 is the most stable and predictable version for production environments since it receives bug fixes and security patches for an extended period from Oracle. This longer support window reduces the need for frequent major upgrades.