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.
Release Notes
Esta sección contiene información sobre cambios rupturistas (breaking changes) en funcionalidades y capacidades de un DXP listo para usar. Para cambios rupturistas o código interno, verifica este enlace.
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-managerbut 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:returnstatements 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 useletorconstnext 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.
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.
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.