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.

Liferay DXP now allows on-demand migration of Virtual Instances across different installations, making existing environments portable and easier to manage—especially in cloud-based deployments. Whether you're moving from on-premise to Liferay SaaS, or just shifting between environments (like UAT to Production) on the same installation, this feature simplifies the process by allowing instances to be migrated, instead of the entire database.

Feature can be enabled with Beta Feature Flag: LPD-11342

With the upcoming release of Jakarta and new application server versions, Liferay is focused on becoming a full feature enterprise platform. Supporting Java 17 prevents usage of Java 21 features that will improve performance and reduce cloud costs. We are marking Java 17 for deprecation as we plan to fully focus on Java 21 in 2026.

This feature aims to enable all fields of an object to be localizable and displayed according to the user's chosen locale settings.

Key Benefits:

• The localization feature will support all existing locales in the system

• Custom Object entries and Modifiable System Objects entries

• Localization settings are now managed at the individual field level

This feature provides a way for customers to consume object validations and manage the experience for end users as they require.

Key Benefits:

• In multi-step forms, end user data can be validated in each step without persisting the data

Data from third party systems can now be managed in DXP through the use of Proxy Objects. Customers can now rely on a transversal OAuth 2 with proper SSO implementation to display data in DXP with the use of Liferay’s low code frontend application building capabilities.

Important: Because the data does not persist in Liferay’s database, some limitations are placed on proxy objects. Learn more.

Managing and synchronizing content across multiple environments just became easier and more reliable. With this release, Liferay expands the capabilities of the Batch Engine by introducing two powerful enhancements:

1. Batch Delete by External Reference Code – Users can now delete items using external reference codes instead of internal IDs, making batch deletions simpler and more consistent across environments.

2. Import Strategy Support for Deletion – When performing a batch delete, users can now define whether the operation should be partial (stop on error) or complete (continue even if some items fail), offering more control and fault tolerance during the process.

Together, these updates streamline how teams manage bulk deletions—especially in environments that rely on external identifiers or require consistent data maintenance across staging, production, and other instances.

Key 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.

In order to add more flexibility to every execution in batch engine, we have added a new parameter ( batchExternalReferenceCode ) to be capable to send it to the backend without updating the ERC of the import task.

Key Benefits:

• Simplicity of execution with one parameter for each purpose.

• Add new capabilities for all entities that supports batch.

We made sure to be able to configure the most relevant SCIM providers by implementing their specifications(Microsoft Entra, Cyber Ark, etc.)

Key Benefits:

Implementing SCIM endpoints from top identity providers streamlines and secures user management by enabling automated provisioning, deprovisioning, and syncing of user data across platforms. This enhances security, ensures compliance, reduces manual work, and improves consistency and user experience. With standardized interoperability, it also future-proofs integrations and boosts operational efficiency while offering better visibility and control over identity lifecycle events

Captcha engine needs to be configurable on instance level to satisfy the multi-tenant environments' need. That has to be possible to configure them for one instance without interfering with the configuration for other instances.

Key Benefits:

Enabling CAPTCHA at the Instance level adds flexibility in configurations without affecting global settings. This supports tailored security and user experiences, and enables compliance per instance, all while retaining centralized control when needed

It’s going to be available without enabling the BETA flag, and from now it’s officially supported.

When issues happen during maintenance periods, end users saw an unbranded default maintenance page. This leaves part of the user flow unattended, with customers unable to forward users to the correct next steps. Setting up and managing maintenance pages that work when DXP is down requires technical skills that not all customers possess, making it impractical for many.

Now we allow customers to upload a maintenance page they designed, fitting their brand and instructing customers on what to do. The implementation functions indepedently from their DXP instance so, as soon as they detect a downtime, they can enable the maintenance page in their Cloud Console to be displayed for their users while they address the issue that caused the downtime.

Configuring the scaling behaviour of Liferay is not simple. Customers are required to have a deep understanding of how their application' metrics behave to set their thresholds. Since charges are also incurred depending on the hours and instances scaled, customers can feel confused on the value they are being invoiced. 

That’s why we allowed for customers to set the maximum and minimum number of scaled instances in their Cloud Console scaling page. This means non-technical customers now can control how little or how much they want to spend in scaling their application. Allowing them pinpoint precision when balancing between improved user experience with more instances, and the increase in costs associated with that.

The Liferay Developer Studio installer now includes JDK 21 as a selectable option if it’s available, simplifying the initial setup and providing a more convenient and user-friendly experience for developers wanting to use the latest Java version supported by Liferay.