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

When users have an object entry related to another system object entry, users now need the VIEW resource permission of the related entry in order to add the object entry.

This change was made to enforce data integrity standards across DXP covering potential security breaches our users could encounter. This will affect all object admins modeling object definitions related to the following asset types

• Accounts

• Organizations

• Picklists

• Postal Addresses

• Roles

When object entries are related to an asset in the aforementioned list, users must now have the VIEW resource permission on the related asset in order to ADD the object entry. This also applies to users who are trying to import an object entry with a related asset from the list.

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.

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.

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

• What changed?
  Javascript from fragments is now included in the page using a <script> of type module, instead of embedding the code in a function

• Why was this change made?
  We wanted to leverage all the features available in the javascript modules: JavaScript modules - JavaScript | MDN
  For example: the ability to use import statements

• What is affected?
  Code that is not supported directly in a <script> tag of type module
  For example:

  • return statements outside the scope of a function

  • Automatic variable declaration, for example myVariable = 'value'

• How should I update my features or implementation to better adopt the breaking change?
  Code should be fairly easy to migrate, just remove any return statement, and for the variable declaration you either use let or const next to the variable name const myVariable = 'value'
  As a temporary workaround (would be removed soon), we have added disable to this feature. You have to go to Instance Settings -> Page Fragments -> Fragment Javascript and disable the checkbox

Changed the methods of adding a Collection to specify the ERC when is created. If a customer has Java code that is using these services they should modify it to specify the ERC (or Null) when is called.

The functionality of the Date Facet widget introduced under a Developer FF in LPS-153839 in 2024.Q1, has been integrated into the Custom Facet and now available as GA. The Date Facet widget is no longer available.

Refer to the Date Range and Range Aggregation in the Custom Facet under Search for more details.

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