Liferay’s Countries feature was migrated from being a Commerce feature to a DXP feature, thus Commerce’s Countries page was removed. Users that manage Countries will now be able to manage them through the Countries Management page under the Control Panel.
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.
To bolster permissions management and elevate user awareness concerning content, users will now be prompted to confirm permissions during the initial publishing or saving process, requiring an additional click. Subsequent saving or publishing actions will not require this confirmation.
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.
Content is no longer classified as translated solely upon the translation of its title. Now, when a user translates any field, not just the title, but also the content status changes to "Translating". It will only be considered translated when all fields have been translated.
The "Recent" filter now displays the creation date information instead of the modified date.
The "Mine" filter now displays the creation date information instead of the modified date.
The name of the reserved variable ID has always referred to the article ID so it has been changed to: Article ID. A new ID variable has been added that refers to the ID.
Tag values are now case-sensitive.
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?
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.
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.
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.
Fragments only can be dropped and mapped into the first item of a Collection Display
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.
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.
The filtering options for "With approved versions," "With scheduled versions," and "With expired versions” are now designated as "Approved," "Scheduled," and "Expired," respectively. Rather than filtering all web content with a given status, it now distinctly displays content or versions in the specified status.
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.
We changed the default configuration such that if a Menu Display widget is placed on a Page Template, the default configuration for it will be "Pages Hierarchy" (unless there are no Pages at all on the Site). It will display as "Pages Hierarchy" even if Private Pages are enabled. If Private Pages are enabled, an alert will appear on the Page Template letting the user know that the Menu Display may appear different if the inherited page has the opposite privateLayout value to the menu currently being rendered.
When a Page inherits this Page Template, the alert message does not display on the Page, and the Navigation Menu will be configured for either Public Pages Hierarchy or Private Pages Hierarchy depending on whether the page is public.
The property permissions.view.dynamic.inheritance on the layouts (pages) has been modified. The logic to align with how the property functions in all other models:
It now applies only to the VIEW action.
It is now restrictive: To have VIEW access to a page, a user must possess the VIEW permission on that specific page and on all of its ancestor pages.
Ehcache 2.x is no longer officially maintained by the Java community. Moved DXP internal caching to use Ehcache 3.10.8.
This means any existing ehcache configuration xml files won't be directly compatible and will likely cause errors or unexpected behavior in the new 3.x environment. Users will need to review and rewrite these configurations according to the new 3.x schema.