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

Liferay’s Countries feature was migrated from being a Commerce feature to a DXP feature, thus Commerce’s Countries page was removed. Users that manage Countries will now be able to manage them through the Countries Management page under the Control Panel.

Content is no longer classified as translated solely upon the translation of its title. Now, when a user translates any field, not just the title, but also the content status changes to "Translating". It will only be considered translated when all fields have been translated.

To bolster permissions management and elevate user awareness concerning content, users will now be prompted to confirm permissions during the initial publishing or saving process, requiring an additional click. Subsequent saving or publishing actions will not require this confirmation.

The "Mine" filter now displays the creation date information instead of the modified date.

The "Recent" filter now displays the creation date information instead of the modified date.

A new SEO menu has been added in Instance Settings with an item selector to include specific Sites or all of them, in the sitemap of the Company through the Company's Virtual Host, and the default site cannot be deleted from the list. If the default site has a Virtual Host defined, it will not be added to the company's XML sitemap although listed in the configuration.

Users are currently presented with a group of features that are not relevant in the configuration page for Utility Pages. These non-applicable features have been removed while preserving the essential HTML Title, HTML Description, and SEO configuration elements.

After searching with a keyword and selecting facets, searching with a new keyword (in either using the header Search Bar or any Search Bar widget instance on a page) will clear all active facet selections.

The old behavior can be enabled via the Search Options widget by ticking Retain Facet Selections Across Searches option.

This affects any custom code using Liferay’s API methods User.getRemotePreference(String) and User.getRemotePreferences().

The API supporting logic has to collect and hold cookies in User object, causing unnecessary CPU and memory overhead. These methods were just a convenient shortcut to get the user's current request's cookies with REMOTE_PREFERENCE_ name prefix. The same logic can be done by directly getting necessary cookies from request.

• What changed? Currently, the translatable object fields use the configured languageId from the user. With this change, it is going to use the preferred Locale given by the DTOConverterContext instead.
• Why was this change made? This change is needed in order to return the appropriate translatable object field values for the language setting in the Accept-Language header.
• Who is affected? Every user that calls the translatable object fields.
• How should I update my features or implementation to better adopt the breaking change? Adding or removing (depends on the cases) the Accept-Language header.

This change was made in order to prevent fragment changes propagation when a user changes the cacheable option and then saves it. This was creating performance issues for some customers.

This change will benefit customers in terms of performance, as unnecessary propagations will no longer occur when the cacheable option is changed.

No changes are expected for customers' implementations. Just the awareness that this option is now somewhere else.

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

The AMBackwardsCompatibilityHtmlContentTransformer class was introduced in the Adaptive Media release (~7 years ago) to manage content created before Adaptive Media was implemented. This approach helped to avoid a costly upgrade at the time. However, since much time has passed and newer content no longer requires this processing, we are disabling the AM backward compatibility HTML content transformer by default.

The primary reason for this change is performance: the content transformer can consume significant CPU resources, especially under heavy traffic.

The content transformer can be enabled in Instance Settings > Adaptive Media if necessary.

The "Save as Draft" and "Cancel" options are no longer visible when editing Web Content. Instead, the content is automatically saved as a draft.
With the implementation of autosaving, users no longer need to worry about losing their progress when editing content. Autosaving ensures that all changes are continuously saved in the background, providing peace of mind and reducing the risk of data loss due to unexpected interruptions.

The JVM java.locale.providers setting for DXP has been restored to the default value to account for the move to Java JDK 17 and 21.

Previously, DXP and Portal shipped with and recommended setting java.locale.providers=JRE,COMPAT,CLDR to provide consistent locale behavior for Java 8 and 11 since JRE was previously the default provider. With Java 17 and 21, JRE is now deprecated and the CLDR locale provider becomes the default and recommended provider. See further information from Oracle.

The new recommended value is java.locale.providers=CLDR,COMPAT as it is the new JVM default. The Liferay Tomcat bundles for 2024.Q4 will ship without this JVM property set, since we are using the default.

With this change the default provider, some locale information in the system might display with modified formatting. For example, a Date and Time display may have previously shown as “9/12/24 9:10 PM” but now displays as “9/12/24, 9:10 PM”. This is the expected result from moving to the latest Java locale provider that meets modern language standards.

Fixed a bug that was causing some 404 redirects to direct back to the previous page instead of to the 404 error page.

If any implementations were relying on users being redirected back to the previous page, they might need to be updated to account for the new redirect to the 404 page.

This is a breaking change for Data Sets that are under BETA FF

• Anybody who created data sets before this epic will not be able to see them in Data Set Manager anymore.

• Data Set fragment configuration will no longer display previous data sets as options.

• Data Set fragment placed on a page will no longer show anything.

• The Data Set Views have been removed. From now on a Data Set has only a view.

• New Data Set endpoints are available and working under datas-et-admin (ex: http://localhost:8080/o/api?endpoint=http://localhost:8080/o/data-set-admin/data-sets/openapi.json)

• All Data Set endpoints are still available and working under data-set-manager but not used by the Data Set Manager or Frontend Data Set. Information from created Data Sets before this change is stored in them (ex: http://localhost:8080/o/api?endpoint=http://localhost:8080/o/data-set-manager/data-sets/openapi.json)

More Info: LPD-29979

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.

Until now, when we had 2 ItemSelectorViews with the same name, only one of them was taken into account when rendering. This is more noticeable now with the CMS where we have object definitions like Blogs. In order to allow the users to select all the object definitions and legacy entities, now they appear duplicated when they have the same name.

We recently updated our tracking logic within documents, replacing the previewed event with a new event: impressionMade. To align with this change, we also updated our current API to include a new metric — impressionMadeMetric — which consolidates impressions by summing both the new impressionMade events and the legacy previewed events.

What changed?

The Display tab in the Review Changes screen now renders Display Page Templates and content that uses those templates (e.g., Web Content Articles, Blog Entries). Previously, these were not previewable — the Display tab was either empty or disabled for such content.

Why was this change made?

This change allows content reviewers to see the real end-user layout before publication. It significantly improves quality assurance by reducing publishing errors and increases confidence that the final layout will match expectations — especially for structured content and enterprise use cases (e.g., FHLBNY). This change improves usability and eliminates a gap in the review process that could result in visual inconsistencies post-publication.

How should I update my features or implementation?

• No changes are needed.

What changed?

The Data tab in the Review Changes screen for Web Content Articles now displays all editable fields, including those created via custom structures. It also shows field labels and values exactly as defined by content creators.

Why was this change made?

Previously, only a subset of fields was shown, which often led to missed content changes during the review process. This update makes it easier to catch all modifications, especially in highly customized structures — enhancing accuracy and trust in the publishing process.

How should I update my features or implementation?

• No changes are needed.

What Changed?

The Configuration Headless API now exposes and manages site-scoped configurations that were previously unavailable through export/import operations. During import, existing configurations for a site are now overridden with the incoming configuration data based on groupId scope matching.

Why Was This Change Made?

This change ensures that site migrations are more complete and consistent, including configuration data that was previously missing.

How should I update my features or implementation?

• No changes are needed.

The results of a search haven’t to be shown the content of a fragment is within a collection display and is not indexed.

The change was already done for text editable, since the button fragment have to allow text only, and it was forgotten for the link editable.

The system-wide Mail Settings for DXP were migrated to use the standard system configuration framework.

The system options in Server Administration > Mail were moved to System Settings > Email > Virtual Instance Scope > Mail Settings

The existing settings from previous releases will be automatically migrated during the database upgrade process.

The following portal properties were removed since they are now defined by configuration properties:
LIST OF PROPERTIES

Following standard configuration patterns, Instance Settings > Email > Mail Settings will have default values inherited from the System Settings. The administrator for Portal Instances can now view the default values, override, or reset to default.

Please refer to Configuring Mail - Liferay Official Documentation for additional details.