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.

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.

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.

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:

• Public
• Private

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:

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.

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.

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.

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.

• 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.