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.
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
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.
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.
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.
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.
The "Mine" filter now displays the creation date information instead of the modified date.
The "Recent" filter now displays the creation date information instead of the modified date.
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.
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.
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.
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.
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.
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.
Current options in System Settings > Documents and Media > Cache Control are:
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:
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
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.
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.
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\"}]"
}
]
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.
The |
Solution introduces 2 breaking changes in the data model, because of a “limitation” in the root model assumptions
There were 2 relationships connecting Data Set and Data Set Action depending on the type of action. Now there is only one
type field in Data Set Action object definition has changed. Now it stores the type of action (item, creation, bulk). The old type now goes to target field
As a result, previously saved data set actions will not be manageable by DSM, neither fragment will find them.
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.
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.
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.
All filtering in web content now only applies to the current folder. Previously, certain filters exhibited behavior limited to the current folder and now it has been standardized to all filters.
The guest role from the role selector was disabled since it is not possible for it to work. |
Searching after filtering will clear all existing filters and give a search from the entire data set.
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.