Users can translate text fields from Objects when using Text Input Fragments in Form Containers.
Release Notes
Dynamically show or hide configuration fields in a custom fragment based on user input values.
With the introduction of the new CMS approach for managing object entries, the existing 1:1 nested object entry functionality in the Page Builder (LPD-20213) is now deprecated and will be removed. This feature has proven to be complex and underutilized by end-users.
The new approach, being developed under the CMS 2.0 initiative, will offer a more intuitive user experience for object relationships, allowing users to configure child structures as repeatable or non-repeatable.
The new Side Panel (also known as Info Panel) is a reusable Clay React component that provides a consistent, accessible, and responsive sliding panel for use across Liferay applications. It supports common use cases such as content editing, navigation, and contextual information display.
Key benefits:
We established a uniform look and feel across all instances of the Side Panel, reducing cognitive load and improving usability and also ensured compliance with accessibility standards (e.g. keyboard navigation, ARIA roles), enabling inclusive design by default.
Reduces redundant implementations and streamlines maintenance by offering a centralised, reusable component.
Reinforces design consistency and reusability across the product ecosystem.
The addition of new translations and locales ensures that users in Myanmar, Bosnia & Herzegovina, Ireland and Serbia can interact with the platform in their preferred languages or regional variation.
Key benefits:
Tailors the user experience for specific markets and regions, improving relevance and usability
We made the platform more inclusive by expanding language and locale options.
The Accessibility Checker Component is being deprecated as part of our effort to improve accessibility tooling and simplify our component library. After evaluating its usage and overlap with other accessibility solutions in Liferay, we found it to be redundant and we stopped using it long time ago.
By displaying the blueprint's results in a Collection Display fragment (available since DXP 7.4 U88 as Beta), you can leverage search to return your assets dynamically, and reap the benefits of the fragments toolbox to lay out the page.
Enhanced Type Support
Now, the Blueprint Collection Provider supports asset types (like structured web content and Objects) allowing to map specific item fields beyond the the basic information fields (i.e., asset entry fields) in fragments, depending on the Searchable Types settings of your blueprint.
When selecting Web Content Article as Searchable Types, the subtype selector becomes available
Selecting an available Web Content Structure (Subtype) as Searchable Types in a blueprint
Web Content Article with a specific Web Content Structure selected as subtype in a blueprint
Mapping a Web Content Structure field from a Blueprint Collection Provider with a specific return type in a fragment
Web Content Article with no subtype restriction selected as Searchable Type in a Blueprint
Mapping Web Content Article field from a Blueprint Collection Provider with a specific return type in a fragment
Document with a specific subtype (Document Type) is selected as Searchable Types in a blueprint
Mapping Document Type fields from a Blueprint Collection Provider with a specific return type in a fragment
Object type selected as Searchable Types in a blueprint
Mapping Object fields from a Blueprint Collection Provider with specific return type in a fragment
Message Boards Message selected as Searchable Types in a blueprint
Mapping basic information fields from a Blueprint Collection Provider with return type Asset in a fragment
Opt-in Collection Provider
Configure if a collection provider should be published when creating a new blueprint, or later via the Configuration tab or through the action menu in the table view in Blueprints.
Enabling a blueprint as a Collection Provider on creation
Enabling/disabling a blueprint as a Collection Provider via Configuration later
Enable blueprint as a collection provide via the action menu in the Blueprints admin
Benefits
Access and map type specific item fields fields in fragments for an extend range of types including Web Content Article and structures, Documents and Document Types and Objects.
Limit searches to specific subtypes via Query Settings in Blueprints
Description
Embedded items now include actions (when the headless entity supports)
Filter by Workflow Status via the
filterrequest parameter.Filter field:
statusExamples:
status eq 0,status eq 0 or status eq 2
Benefits
Invoke available actions on the returned items
Filter results by workflow status
Liferay Self-Hosted deployments can update their Elastic stack to this version. For Liferay PaaS projects a new Elasticsearch image will be provided under Liferay Cloud’s Docker Hub account.
Deployments can operate their stack using the latest available, secure and stable version of OpenSearch 2.
Requires to install Liferay Connector to OpenSearch 2.
Liferay Tomcat Bundles and Docker Images ship with Elasticsearch 8.18 as the sidecar search engine.
Benefits
The Elasticsearch server runtime included in Liferay DXP Tomcat Bundles and Docker Images (aka. Sidecar Elasticsearch, located under [Liferay-Home]/elasticsearch-sidecar) is provided as a convenience for local development and testing only. It is neither suitable nor supported for production.
Instead, configure Liferay to connect to Elasticsearch as a self-managed, standalone server or cluster of server nodes.
Collections with Blueprints (FF: LPS-129412) available as since DXP 7.4 U88 is now in RELEASE status and can be enabled via Feature Flags > Release.
Addressing prior limitations, custom cell renderers created with Client Extensions now provide full row data access. This empowers developers with expanded options and greater flexibility for their implementations so they can create a renderer for a cell and include data from all the row mixing the contents. For example, you can create a cell to calculate the volume of a furniture good based on the different dimensions fields.
Benefits
Expand developer capabilities to create more powerful Client Extensions for Data Set Cell Renderers
The Data Set has a revamped experience in terms of selection that also provides a quicker way to contextualize the user interaction.
When facing any of the visualizations (table, card, row) the user can click on the item body to perform single selection. This enhances rapid selection and better interaction.
Benefits
More modern selection pattern that follows industry trends
Clearer states for the user to distinguish when an item is:
Selected (active)
Hovered
Both at the same time
With this release, the Liferay DXP is now built with the modern, cloud native technology provided by the Jakarta EE 10 platform. The legacy Java EE platform will no longer be supported on this and future releases, allowing Liferay DXP to continue to evolve and build innovative solutions to meet your business needs.
Benefits
Liferay DXP now certified on Jakarta-based application servers: Tomcat 10.1, Jboss EAP 8.0, and Wildfly 30. This also provides support for newer specifications such as Portlet 4.0, Servlet 6.0, and Spring Framework 6.0. The update paves the way for faster feature development and rapid security fixes available in the modern Java enterprise ecosystem.
The Beta feature to migrate databases to PostgreSQL has been updated to support all supported database types. PostgreSQL is the Liferay recommended database server, especially for PaaS and SaaS users and Liferay provides this tool to simplify the migration.
Benefits
Users on MariaDB, SQL Server, Oracle DB, and IBM DB2 are now able to migrate their database to PostgreSQL. The tool was previously limited to users on MySQL. Now all users have access to the DXP and Cloud performance benefits of using PostgreSQL.
The DXP database upgrade process has been enhanced with a suite of verification checks that are executed before any data modifications are made.
These checks have minimal impact on the overall upgrade process execution time, but they can be optionally disabled with the property upgrade.database.preupgrade.verify.enabled=false
Benefits
It can be frustrating when a database upgrade process executes a large amount of modifications to the system and then fails due to a misconfiguration, prompting the need to restore the database and restart the process. Now the database upgrade process will perform a series of configuration checks and report them to the user before modifications are needed. This prevents the need to always restore the database or document library before re-running the upgrade. The upgrade report will still be generated if the preupgrade checks fail, and provide details of any issue.
Allow users to call the {scopeKey} using the external reference code when creating a custom object with site scope.
Ex: /scope/{scopeKey}/...
Now, ID, Name and ERC are supported for scopeKey.
Users can now refer to their custom external reference codes for sites when interacting with object endpoints.
This feature adds workflow support for Root Models. Child object definitions which are part of a root context will inherit the workflow configurations of the root parent. This simplifies the administration of objects which are part of root model applications.
Friendly URLs, also known as clean URLs or pretty URLs, are web addresses that are human-readable and search engine-friendly. They typically use descriptive keywords instead of cryptic file names or query strings. Users can define a friendly URL for entries, making them more human readable and search engine friendly.
New improvement to make easier the way to promote content among environments. Liferay expands the capabilities of the Batch Engine by introducing a powerful tool for site scoped entities:
- Batch Delete by External Reference Code ( Site Scoped entities ) – Users can now delete items using external reference codes instead of internal IDs, making batch deletions simpler and more consistent across environments.
Now, covering all scopes, the way teams manage bulk deletions is more simple and safe because it is based on the use of external identifiers so the consistent data maintenance across staging, production, and other instances is possible without changing between environments
Key Business Benefits
More reliable environment synchronization: External Reference Codes allow you to delete the same entities across different environments without depending on internal IDs, reducing risk of mismatches.
Simplified bulk deletion workflows: Deleting large sets of data is now easier, with fewer manual steps and lower chance of errors.
Greater control over delete operations: Choose whether the process should stop on errors or complete fully—helping teams tailor the behavior to fit their operational needs.
Increased resilience and fault tolerance: Deletion jobs are less likely to fail entirely due to minor issues, ensuring smoother maintenance processes.
Consistent support across entities: These enhancements are available for all entity types supported by the batch engine, making them broadly applicable across different use cases.
Context: Both features are part of the “Promote content among environments” strategic initiative.
Describe the feature:
With the migration to Jakarta, RESTBuilder needed to adapt to be able to generate the classes with the right namespace.
Use the javaEEPackage property to define whether to use javax as namespace (for pre-Jakarta versions of Liferay) or set the value to “jakarta” for newer versions.
In our headless APIs, we have many endpoints with /siteId/{siteId}/ as part of the path for many entities. Now, siteId not only accepts the siteName or the siteId as value, but also the External Reference Code of the site can be used.
Until now, when executing a staging import, users could choose, prior to the import, to delete all existing information in the destination environment.
This option has been deprecated due to its low usage (verified directly with clients and partners) and the high risk it entails, as deletion affects not only the elements already in the import but also their related entities. This could lead to the loss of necessary information or the possibility of some entities becoming disconnected from the rest, making both the import and error resolution extremely complicated due to the lack of a list of affected elements. There will not be a substitution, so the alternative will be to delete the elements manually, either from the UI, API or directly in the database before performing the import.
When executing a staging import, users could choose different strategies to update the data.
”Copy as new” was one of the option, that allow the importer to create new items if they were already in the system. This could lead to create more elements than expecting that later on the user would need to clean. We are deprecating this feature in order to simplify the UI and avoid users to do mistakes.
There will not be a substitution.
The Captcha extension point allows customers to integrate custom or third-party CAPTCHA solutions into their system, enabling greater flexibility and control
Key benefits
Removes restrictions on supported CAPTCHA providers
Empowers customers to choose and configure CAPTCHA solutions that best suit their needs
Enhances extensibility and adaptability for diverse use cases and compliance requirements
Just-in-Time (JiT) user provisioning for OIDC and SAML enables automatic synchronization of user data, including user groups at every authentication event. This ensures that user profiles are always up to date
Key benefits
Ensures real-time synchronization of user attributes and group memberships
Reduces administrative overhead by eliminating the need for pre-provisioning
Enhances security and compliance with up-to-date access control
Improves user experience by streamlining access without delays
We improved the password reset function on the Forgot Password Utility Page to prevent it from redirecting users to the old Forgot Password page.
Key benefits
Consistent page experience
The FF changes from Beta to Release
Users now have more access to several more metrics on their metrics page. Improving their visibility and troubleshooting capabilities.
Highlights
New metrics visible in the metrics page;
New metrics improve visibility of platform and infra elements, greatly speeding up troubleshooting and understanding of platform behaviour.
The selection of metrics leverages our deep understanding
In order to assist users in the migration to Jakarta EE required for 2025.Q3 and beyond, Blade and Workspace users now have a command to automatically convert their source code from Java EE to Jakarta EE for DXP-provided libraries.
Benefits
This tool simplifies the process for users migrating custom code to Jakarta. Providing:
In-place source code transformation from
javaxtojakartafor custom development projects using DXP-provided librariesLiferay-specific dependency mapping
Portlet 4.0 conversion
Integration into Liferay Workspace
Supports source code conversion regardless of deployment method (e.g. JAR or WAR)
This tool is supported by Liferay to convert source code for compatibility with the Jakarta libraries provided by Liferay DXP.
Allow applications built on top of Service Builder to leverage the benefits of the Liferay Objects framework
Key benefit:
Applications built on top of Service Builder can now be migrated to Liferay Objects
The batch engine's export endpoints now support filtering for object entries. This addresses a previous limitation where filtering was not applied to object entries during batch exports. This update ensures consistent data handling and filtering behavior across all entity types.
Key benefits:
- Object entries Personalization
- Equalize capabilities for all entities
Until now, there was no way in batch engine to export and import object entries and their permissions simultaneously. This new capability allows users to do that, streamlining workflows and reducing manual effort.
Key benefits:
Execution in only one call.
Possibility for users to choose to take into account (or not) permissions with object entries.
Data imports, using batch engine, now allows users to preserve content creator information (if required). Previously, imported content with batch was always assigned the user performing the import, resulting in loss of original authorship data when moving content. This update ensures accurate attribution of content ownership (if required).
Key benefits:
Able to keep critical user information during data promotion between environments
Can be configured separately per import process
Implemented proactive access token management with automated email notifications. Users will now receive alerts 1 month, 10 days, and 1 day prior to token expiration, allowing for timely renewal and preventing service disruptions. Notifications are automatically cancelled if a new token is generated.
Key benefits:
Users are notified before token expiration, allowing for timely renewal and uninterrupted access.
Reducing administrative overhead, as automated notifications eliminate the need for manual monitoring and intervention.
By prompting timely renewals, the risk of using expired and potentially compromised tokens is minimized.
The vendor has deprecated OpenSSO/OpenAM, so there's no reason for us to keep it. The alternative, which is PingAM can be integrated using our existing OpenID connector or SAML Authentication.
The SSL Certificate Management view now provides expiration alerts for certificates nearing expiration (e.g., within 30 days) and those that have already expired. Certificates must now be defined exclusively through the LCP.json file, simplifying management and ensuring consistency across deployments. This update reduces manual errors and ensures secure and uninterrupted deployments.
Highlights:
Expiration Alerts: Notifications for certificates nearing expiration and those already expired, with clear visual indicators.
Exclusive LCP.json Configuration: Certificates can only be defined through the
LCP.jsonfile.Improved Visibility: Organized list view showing certificate names, types, associated domains, and expiration dates.
Proactive Management: Tools and alerts to help users maintain secure SSL/TLS configurations.
The Marketplace release of the Liferay Connector to OpenSearch 2 provides an alternative to Elasticsearch for Self-Hosted Liferay deployments.
This connector integrates Liferay DXP with OpenSearch 2.12+, the open source and enterprise grade search engine. OpenSearch offers lexical search for text data, robust scalability and extensibility, and vector search for applications using embeddings, such as Liferay's Semantic Search.
The installation of this app requires specific configurations covered in the official documentation. For detailed compatibility information, see the Search Engine Compatibility Matrix.
The OpenSearch integration is currently a Beta feature with the intention to make it GA in the future.
Liferay Cloud now provides CI/CD support for Client Extensions on Liferay PaaS. Developers can integrate Client Extensions into their Git-based CI/CD pipelines, ensuring automatic builds and deployments alongside core Liferay services. This update enables automated validation, independent deployments, and faster release cycles for Client Extensions.
Highlights:
Dedicated CI/CD Pipeline: Separate build pipeline for Client Extensions to prevent conflicts with core Liferay services.
Automated Builds: Every commit triggers a new Client Extensions build, packaged as a LUFFA archive.
Independent Deployments: Client Extensions builds deploy separately, improving release flexibility.
Seamless Integration: Works with existing Git-based workflows on Liferay PaaS.
Zero Downtime Deployments: Deploy client extensions without affecting the main Liferay service.