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.
Release Notes
This section contains information about breaking changes in out-of-the-box DXP features and capabilities. For breaking changes or internal code, please check this link.
What Changed?
Previously, some Modification Conflicts and all Modification Deletion conflicts required manual resolution. These cases would show up in the Checking Changes screen, requiring manual user action to be resolved. They are now automatically resolved by overwriting production with the changes made in the publication and won't be displayed in the Checking Changes screen.
Why Was This Change Made?
The previous behavior required users to manually address many types of conflicts, which was usually a time-consuming effort. The new behavior reduces the friction in the publishing process while guaranteeing publications’ users they will be able to publish the needed modifications.
Who Is Affected?
All publication users are affected, but the focus is on the ones responsible for solving the conflicts and publishing the content.
How Should I Update My Features or Implementation to Better Adopt the Breaking Change?
Consider that now Publications’s users have more power to overwrite production changes. If you understand that the end-user scenario still requires human verification in Modification Deletion cases, the previous behavior can be restored by using the Modification Deletion Conflicts Toggle on Instance Settings > Publications.
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.
The two separate configuration menus in the widgets of content page has been merged into a single menu.
According to the deprecation feature flag pattern definition, the feature flag has been moved under Instance Setting.
The Collection Page has been removed from the page administrator. An upgrade path substitutes the Collection Pages for Content Pages with a collection display without any functional change.
Solution introduces 2 breaking changes in the data model, because of a “limitation” in the root model assumptions
There were 2 relationships connecting
Data SetandData Set Actiondepending on the type of action. Now there is only onetypefield inData Set Actionobject definition has changed. Now it stores the type of action (item, creation, bulk). The oldtypenow goes totargetfield
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.
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.
When performing a GET on text fields using the headless API and results in empty contents, the output returns ”” instead of being skipped. This change gives more flexibility to the users to decide what each user will do with the information.
Users should review all GET requests on text fields to adapt to this change.
Currently, when a user make a call to Batch in order to import any entity, the error returned has a different structure than a regular call to the Rest API. Specifically, the structure that is different is the one related to "failedItems" information.
With this change, users will have the same structured information no matter the endpoint they are using so matching errors and show it in the UI will be more simple.
The main change is:
Current structure:
"failedItems": [
{ "item": "{\"properties\": {\"field1\": 4, \"field2\": 5}}",
"itemIndex": 1,
"message": "com.liferay.portal.kernel.exception.ModelListenerException: com.liferay.object.exception.ObjectValidationRuleEngineException: Field 1 must be greater than,Field 2 must be greater than 5" }
]
New structure:
"failedItems" : [ {
"item" : "{\"properties\": {\"field1\": 4, \"field2\": 5}}",
"itemIndex" : 1,
"message" : "[{\"objectFieldName\":\"field1\",\"errorMessage\":\"Field 1 must be greater than\"},{\"objectFieldName\":\"field2\",\"errorMessage\":\"Field 2 must be greater than 5\"}]"
}
]
The |
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.
Fragments only can be dropped and mapped into the first item of a Collection Display
Collection Pages have been removed from page administrator.
Documentation: LRDOCS-14626: Documentation LPD-45659 - Remove Collection Pages from page administratorClosed