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.
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.
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 functionWhy 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 statementsWhat is affected?
Code that is not supported directly in a <script> tag of type module
For example:return
statements outside the scope of a functionAutomatic 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 uselet
orconst
next to the variable nameconst 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.
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.
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.
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.
Sites are not browsable for non-admin users in Breadcrumb portlet when the site has Membership restricted or private.
The Default Layout permission was replaced with the current Group check.
Disable Group membership checking since it has no relationship to layout browsability.
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.
When we create a new Site the Allow Manual Membership Management option will be disabled by default to avoid uploading malicious files to the Documents and Media portlet.
Searching after filtering will clear all existing filters and give a search from the entire data set.
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
andData Set Action
depending on the type of action. Now there is only onetype
field inData Set Action
object definition has changed. Now it stores the type of action (item, creation, bulk). The oldtype
now goes totarget
field
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.
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.
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.
According to the deprecation feature flag pattern definition, the feature flag has been moved under Instance Setting.