According to the deprecation feature flag pattern definition, the feature flag has been moved under Instance Setting.

The Collection Page has been removed from the page administrator. An upgrade path substitutes the Collection Pages for Content Pages with a collection display without any functional change.

• Solution introduces 2 breaking changes in the data model, because of a “limitation” in the root model assumptions

  • There were 2 relationships connecting Data Set and Data Set Action depending on the type of action. Now there is only one

  • type field in Data Set Action object definition has changed. Now it stores the type of action (item, creation, bulk). The old type now goes to target field

• As a result, previously saved data set actions will not be manageable by DSM, neither fragment will find them.

In order to simplify the system processing of JSPs and improve performance, 2025.Q1 removes the optional configuration previously enabled by the property work.dir.override.enabled=true. JSPs will now always remain within the OSGi bundles that deploys them. This feature was already disabled by default due to the performance cost.

Java 17 or 21 is already required for Portal runtime since 2024.Q2 release, but the source code was still able to be compiled on Java 8. With the 2025.Q1 release, Java 17 or 21 will also be required for compile.

When performing a GET on text fields using the headless API and results in empty contents, the output returns ”” instead of being skipped. This change gives more flexibility to the users to decide what each user will do with the information.

Users should review all GET requests on text fields to adapt to this change.

Currently, when a user make a call to Batch in order to import any entity, the error returned has a different structure than a regular call to the Rest API. Specifically, the structure that is different is the one related to "failedItems" information.

With this change, users will have the same structured information no matter the endpoint they are using so matching errors and show it in the UI will be more simple.

The main change is:

Current structure:

"failedItems": [ 
{ "item": "{\"properties\": {\"field1\": 4, \"field2\": 5}}", 
  "itemIndex": 1, 
  "message": "com.liferay.portal.kernel.exception.ModelListenerException: com.liferay.object.exception.ObjectValidationRuleEngineException: Field 1 must be greater than,Field 2 must be greater than 5" } 
  ]

New structure:

"failedItems" : [ {
    "item" : "{\"properties\": {\"field1\": 4, \"field2\": 5}}",
    "itemIndex" : 1,
    "message" : "[{\"objectFieldName\":\"field1\",\"errorMessage\":\"Field 1 must be greater than\"},{\"objectFieldName\":\"field2\",\"errorMessage\":\"Field 2 must be greater than 5\"}]"
  } 
  ]

• Granting “Update” Permissions: Granting “Update” permissions to a role enables the user to edit a folder's properties, like its name and description.

• Granting “Advance Update” Permissions: Granting “Advance Update” permissions to a role enables the user to update the workflow associated with a folder. The folder's properties, such as name and description fields, remain disabled and cannot be edited.

• Users subscribed to a web content or a folder will not receive notifications for assets in the pending state unless they are directly involved in the workflow review process

• This change is meant to match the current behavior of Documents & Media

When a user is deleted in Analytics Cloud, they will first be suppressed before being permanently deleted. As a result, you will see two requests per user—one for suppression and another for deletion.

Previously, each user deletion generated two separate requests. Now, all users are grouped into a single suppression and deletion request, reducing the number of requests. For example, each request will now contain a list of all affected email addresses instead of generating individual requests per user.

Users can verify deletion logs in:
Analytics Cloud > Settings > Data Control & Privacy > Request Log.

What changed?
A new bulk operation feature allows users to select and manage multiple changes within a publication. Users can now move or discard changes in bulk via a management bar. This simplifies managing large publications.

Why was this change made?
Previously, users had to manage each change individually, which was time-consuming. This change enhances user efficiency and reduces the administrative burden, making the platform more scalable for large publications.

Is the new behavior better for users?
It significantly saves time and effort, making it easier to manage multiple changes quickly. This results in a smoother, faster user experience when handling large volumes of changes.

Who is affected?
Users who manage large publications or need to handle multiple changes will benefit from this update. It streamlines the process for users who frequently move or discard changes.

How should I update my features or implementation to better adopt the breaking change?
If needed, this feature can be enabled/disabled through the Feature Flag on Instance Settings > Feature Flag > feature.flag.LPS-171364=true or Bulk Actions for Publications (LPD-20183)

What changed?
The review change screen now includes a progress bar that provides real-time visual feedback during the publication process. Users will see the progress bar while waiting for their publication to go live, indicating how much time remains in the publishing process.

Why was this change made?
Previously, users had no visual indication of how long the publishing process would take. This change improves user experience by providing transparency and better manage their expectations.

Is the new behavior better for users?
The new progress bar enhances user satisfaction by offering clear, real-time feedback. It helps users understand the publishing timeline, reducing uncertainty during the process.

Who is affected?
All publication users are affected, but the focus is on those handling large or complex publications, where waiting times could previously be unclear.

How should I update my features or implementation to better adopt the breaking change?
No change is needed in the current process.

What changed?
A publication size classification is now displayed in the review changes screen, categorizing publications as Light, Medium, or Large based on their size. A popover explanation appears when users hover over the classification, providing insight into the potential impact of the publication size on the publishing process.

Why was this change made?
This change helps users understand the scale of their publications, allowing them to plan the publishing process better. It aims to prevent performance issues and reduce conflicts by encouraging users to allocate more time for larger publications.

Is the new behavior better for users?
The new classification provides clearer insight into the publication's complexity, helping users avoid unexpected delays. It also allows them to take proactive steps in managing their workflow, ensuring smoother publishing processes.

Who is affected?
All publication users are affected, but it is more focuesd on user who deal with multiple changes and users with deadlines to accomplish when publishing their website.

How should I update my features or implementation to better adopt the breaking change?
If needed, this feature require the Feature Flag on Instance Settings > Feature Flag > Additional Context in Publications Toolbar (LPD-20556) to work fully.

Fragments only can be dropped and mapped into the first item of a Collection Display

Collection Pages have been removed from page administrator.

Documentation: LRDOCS-14626: Documentation LPD-45659 - Remove Collection Pages from page administratorClosed

The SEO configuration of a page has been moved from DDM to standard forms

The property permissions.view.dynamic.inheritance on the layouts (pages) has been modified. The logic to align with how the property functions in all other models:

1. It now applies only to the VIEW action.

2. It is now restrictive: To have VIEW access to a page, a user must possess the VIEW permission on that specific page and on all of its ancestor pages.

LRDOCS-15042

Ehcache 2.x is no longer officially maintained by the Java community. Moved DXP internal caching to use Ehcache 3.10.8.

This means any existing ehcache configuration xml files won't be directly compatible and will likely cause errors or unexpected behavior in the new 3.x environment. Users will need to review and rewrite these configurations according to the new 3.x schema.

The AMD Loader has been removed. Liferay DXP officially supports ESM, which is the official standardized module system for JavaScript, while AMD was a third-party solution. By adopting ESM, products align with the language's native capabilities and future direction. Modern browsers now natively support ESM, allowing for direct use without transpilation or additional loaders. This can lead to reduced bundle sizes, faster initial page loads and simplified development workflows.

Users who are using amd-loader must migrate to the Liferay.loader. See link for more details.

The "Warehouse" field has been removed from the Shipping Option's details panel.

This field was previously available as a selection field within the shipping option configuration, but it is crucial to understand that it was purely informational and did not enforce any actual warehouse restrictions or logistics.

The "Warehouse" field was identified as a source of potential confusion for administrators. Its presence, despite being purely descriptive, could lead to the incorrect assumption that it played a role in applying warehouse restrictions to a shipping option. To ensure clarity and prevent any misleading interpretations, we have decided to remove this field entirely.

Important Note for Administrators: If you used this field for metadata, this information will no longer be visible. We strongly recommend transferring any critical metadata to an alternative location before upgrading to avoid loss. This change does not impact actual warehouse configurations or shipping logic.

This portal-ext property was to Instance/System settings so that the property could be controlled during runtime. Users will need to reconfigure portal if they are currently using this property.

See https://github.com/liferay/liferay-portal/commit/0b2ee06d7ee20972bc8ebd84e2c1c10fb9a41763

What changed?
With the introduction of customizable publication-level permissions, all permissions, including publishing to production, can be changed by an admin or a user with the appropriate "Manage Permissions" capability.

Why was this change made?
Previously, Owners were automatically given the ability to publish content to production, which led to unintentional production changes, especially in environments using Sandbox mode or implementing stricter governance policies. This behavior was inconsistent with customer expectations and Liferay’s broader permission model.

Who is affected?
How should I update my features or implementation?
No need for Updates. You may want to use the new "Permissions" on Publication Settings section to "Edit Permissions" if needed.

What changed?
A new warning message now appears when "Sandbox Only" mode is enabled but publication Owners retain permission to publish. This does not change the behavior of Sandbox mode but introduces a new UI-level validation to prevent unwanted changes.

Why was this change made?
This message prompts admins to review permission settings and avoid potential production changes made in error. The goal is to support secure sandbox and prevent publishing mistakes by making permissions more transparent.

Who is affected?

Publication users with enough access to configure Publications and enable Sandbox mode.

How should I update my features or implementation?

No need for Updates. When enabling Sandbox Only mode, look for the new warning message and use the "Edit Permissions" option to review Owner permissions.

What changed?
Admins can now fully customize the permissions for the "Owner" and other roles in Publications. This includes the ability to revoke critical actions such as "Publish on Production." Previously, users who created a publication were always granted full permissions by default, including publishing rights.
Why was this change made?
This change was introduced to address a gap in the permission model that could unintentionally allow users to publish content to production—even when Sandbox mode was enabled. By enabling permission customization, we close this loophole, giving administrators better governance over content workflows. The new behavior improves system security and reduces the risk of misconfigurations, especially in environments where publishing control is critical.
Who is affected?

All publication users are affected, but the changes are focused on Admins and Publication’ Owners

How should I update my features or implementation?

No need for updates. When reviewing the permissions assigned to the "Owner" role in each publication be sure to use the new "Edit Permissions" modal.

What changed?

• Users can filter Navigation Menus by creation or modification date.

• API’s now allow retrieving navigation menus by External Reference Code, rather than only by internal IDs.

Why was this change made?

This change improves the reliability and usability of cross-site migration tools, enhances content governance with complete permission handling, and introduces stable referencing via ERCs.

Who is affected?

Developers and Site administrators requesting Navigation Menu’s via Api’s.

How should I update my features or implementation?

No changes are needed. Users may want to use External Reference Code when referencing navigation menus.

The Java EE libraries are no longer in active development. DXP has moved to the modern and evolving enterprise Java platform, Jakarta EE 10. With the migration of the system to Jakarta EE, any Java EE libraries (javax.*) are no longer compatible and must be replaced with the Jakarta EE 10 (jakarta.*) updated versions. This also breaks any 3rd party libraries that rely on Java EE packages. Libraries must be updated to a Jakarta-compatible version.

This affects any users with custom code deployed to the Liferay DXP JVM. Client Extensions are not affected since they run in an external process.

With the migration of the system to Jakarta EE, the following deprecated application servers are no longer supported:

1. Apache Tomcat 9.0.x

2. JBoss EAP 7.4

3. Wildfly 26.1

4. Weblogic 14c

Users must migrate to a Jakarta EE compatible application server:

1. Apache Tomcat 10.1.x

2. JBoss EAP 8.0

3. Wildfly 30

(Weblogic 15 has not been released, but we are monitoring its availability and plan to add support in a future DXP release).

This change gives users access to actively maintained application servers that leverage the modern Java enterprise ecosystem.

PortletMVC4Spring has migrated to a new version based on Spring 6.0 and Jakarta EE. Users must migrated their existing PortletMVC4Spring projects to version 6.x

The previous versions of PortletMVC4Spring were deprecated due to dependency on Java EE and will no longer work with 2025.Q3 release.

The current version of Liferay Faces was deprecated due to dependency on Java EE and will no longer work with 2025.Q3 release.

However, Liferay is still preparing a new version of the Liferay Faces, based on Jakarta EE 10 and Portlet 4.0, scheduled for release later this year. Since the dependencies in DXP are already migrated, it is expected that the new Faces release will be compatible with 2025.Q3

Support for these application servers is removed from 2024.Q3 or later since they are no longer receiving updates from the vendor.

Wildfly 26.1 and Jboss EAP 7.4 remain fully supported

With the new support of Java JDK 17 and 21 runtimes, Java 11 will no longer be supported for DXP runtime on 2024.Q3 or later. 

Liferay Workspace offers support for re-compiling custom modules on JDK 17 or 21.