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.