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.

When we create a new Site the Allow Manual Membership Management option will be disabled by default to avoid uploading malicious files to the Documents and Media portlet.

Searching after filtering will clear all existing filters and give a search from the entire data set.

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.

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

The two separate configuration menus in the widgets of content page has been merged into a single menu.

Current options in System Settings > Documents and Media > Cache Control are:

• Public
• Private

And Private is the default option.

From now on, we are adding a new option No Cache that will allow configure this option to “private, no-cache, no-store, must-revalidate" and it will be used as default value, so it changes current default behavior:

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.

Previously our AB Testing feature supported multivariate testing. With the addition of multiple variants, the time to completion and the calculations required would increase exponentially. This caused many issues for our customers. As such we have decided to pare back this functionality to provide a higher quality experience for our users. Now our AB Testing feature only supports 1 variant, in addition to the control. This makes our feature truly an AB Test rather than a Multivariate Test. There is the possibility of re-enabling multivariate testing in the future, but that will depend on the needs from our customers.

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.

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

Sites are not browsable for non-admin users in Breadcrumb portlet when the site has Membership restricted or private.
The Default Layout permission was replaced with the current Group check.
Disable Group membership checking since it has no relationship to layout browsability.

The configuration sections in Utility Pages are not enabled, as the other pages, due to their use being more restricted. The implementation of these settings should occur by analyzing each case.

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.

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.

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

From now on, the segments tab for the Administrator role will no longer be displayed in the assignees' tab. Assigning the Administrator role through segments is not allowed.

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.