As mentioned in the new features section the following properties having been transformed in configurations, so they are no longer available in the properties files:

• session.timeout.auto.extend
• session.timeout.auto.extend.offset

With the upgrade of the client libraries, the minimum compatible Elasticsearch minor version shits to 7.17.x.

When the server is lower than the expected version, the DXP won't start-up, but fail with an error in the DXP console:

10-22 10:45:22.619 ERROR [main][ElasticsearchSearchEngine:375] Elasticsearch node es-node-1 does not meet the minimum version requirement of 7.17

The self bootstraping style *SearchRegistrar has been changed to service collecting of ModelSearchConfigurator.

Indexer registration code for custom entities has to be adjusted to become an OSGi service of type ModelSearchConfiguratorand to move all previous ModelSearchConfigurator setter call parameter as corresponding ModelSearchConfigurator getter return value.

What changed?

From Liferay DXP 2024Q2 onwards, localizable object entry fields now default to the instance's language setting, replacing the previous user-language default.

Why was this change made? Is the new behavior better for users?

This change was implemented to ensure consistent language configuration. The new behavior is indeed better for users because:

• It prevents discrepancies that could occur when users with different language settings interacted with the same object entry fields.

• It provides a unified experience across all user interactions.

Who is affected?

Customers using or upgrading from versions prior to Liferay DXP 2024Q2 are affected by this change.

How should I update my features or implementation to better adopt the breaking change?

To adapt to the new behavior:

• Check your existing localizable object entries' default language settings.

• Adjust these settings to match the instance language if needed.

This ensures consistent language defaults and creates a uniform experience for all users.

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.

Tag filter widget used to sort tags in alphabetical order but it seems customers expect to see the tags with more uses first. We think this change make sense so we have modified the behavior for this widget.

What Changed?
The Out-of-date feature, which allows publications to be labeled as “Out-of-date“ and prevents Users from publishing their content, is now off by default.

Why Was This Change Made?
The users still wanted to be able to publish publications created before Liferay upgrades, and now the conflict management improvements make this possible and safe.

Who Is Affected?
Users who have upgraded or plan to upgrade Liferay while having ongoing publications.

How should I update my features or implementation to better adopt the breaking change?
If needed, this feature can be enabled/disabled through the toggle on Instance Settings > Schema Version Check Enabled, which is off by default.

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

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

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.

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 results of a search haven’t to be shown the content of a fragment is within a collection display and is not indexed.

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.

The Object Inheritance feature has been updated to support more flexible scenarios, which introduces changes to the previous behavior:

• Child definitions can now be associated with multiple parent definitions.
  Previously, a child could only inherit from a single parent.

• Child entries can now exist without a parent (standalone entries).
  Before this change, every child entry was required to belong to a parent.

• The relationship field is no longer mandatory at the object-definition level.
  Previously, the relationship field was always required when inheritance was enabled.
  Now, it becomes mandatory only when the entry is created in the context of a parent.

• Permission and configuration inheritance now depends on whether the child entry has a parent.
  Standalone entries no longer inherit permissions or configuration from a root object.

At the LPD-46627: Enhancing SAML to be able to Sync User GroupsClosed story we modified the SAML userGroups membership management according to the portal’s standard way. With that we introduced a namespace for the attribute which seems causing inconveniences to customers, described in the LPD-66611: userGroups Attribute Name Changed to membership:userGroups, Breaking Liferay IdP IntegrationsClosed bug ticket.