Since Publications provides a final end point for users to review changes, it would benefit content editors tremendously if they could also review their workflow changes.

There is an unacceptable decrease in performance observed within large Publications. With publications housing a large number of individual changes, the current system struggles to maintain acceptable performance levels, especially during conflict checking and publishing publications. These two phases leverage handwritten SQL queries to perform those tasks that allow Publications a shortcut through our persistence layer to maximize performance in small publications. In large publications though, further considerations must be taken to ensure consistent performance.

Allow users to map Repeatable fields of a Web Content Structure already defined in Fragments and Collection Displays.

The /search and /suggestions APIs comes with the following enhancements:

• New, optional scope parameter supporting Site (Group) IDs and External Reference Codes (ERCs) in /search. The scope parameter of /suggestions has also been updated to have the same semantics.

• /search now is in RELEASE status.

• The APIs now are available under the /o/search/v1.0/ endpoint with backward compatibility for current /o/portal-search-rest/v1.0 calls through server-side forward.

Refer to the documentation for more details.

Clause Contributors configuration is now stored within the blueprint’s JSON with a smaller footprint, reducing the size of a blueprint by more than 90% when using the default setting (all contributors enabled → Enable All) or the new Disable All option.

The behavior of the different options is as follows:

• with Enable All, all current and future query clause contributors introduced to the platform will be enabled automatically. Disable All behaves the opposite way,

• with Customize, the configuration is locked to the specified contributor list.

The selection filters of the Data Set Manager has been revamped to allow chosing different type of sources. On top of the picklist, now the admin user may select an API Headless as filter values source, so the filter values might be populated with the values coming from the API response. This allow users to have a more automated process on the filter creation.

The CX Filter allows developers to build their own filters, with on demand bussiness logic and UI, to be added to a Data Set in the Data Set Manager and then be used for end-users in the Data Set. With this new value, the Client Extension can be generic, and the same Client Extension can be used to build filters that filter by different fields.

User session replication has been optimized for the Tomcat application server.

Users can configure a reset for the number of guest submissions allowed in a given timeframe.

Users can add the necessary security layer to avoid misuse of scripting in Objects and Workflow Actions.

Objects is used for a wide range of use cases, some of them more technical than others. This feature will allow users to configure where they want their objects to be listed. Thus, creating unnecessary complexity and reducing cognitive load on other users.

Users can now configure their objects to observe the guest user’s locale and send email notifications based on the guest user’s language preference.

The guest user’s language preference is determined by the language the guest user used when submitting the form. If a locale cannot be determined or a notification template does not exist, then the notification will be sent in the instance’s default language.

For those Objects that have the translation active, users can not get this entry information using GraphQL. In order to improve GraphQL capabilities, we have exposed the _i18n properties, so any user can retrieve it.

For making the Sign In portlet related functions easily customizable for the end users we want to simplify the portlet as much as we can. We need to remove all it’s configuration or functionality that can be handled in higher level.

Currently, the customer has to resort to email reports to see their autoscaling. We are making this information much more available and searchable, allowing the user to better understand their autoscaling behaviour.

Liferay DXP provides a variety of developer tools that include a robust build script framework, lightweight CLI utilities, and IDE tools. We have recently released new versions of Liferay Workspace and the IDE tools, which include Liferay Developer Studio, Liferay Eclipse Plugin, and Liferay IntelliJ Plugin. The main benefits include:

• Alignment with the platform itself: The tools now support our quarterly releases, giving access to development on Liferay DXP's latest features.

• Latest Java version support: Compatibility with JDK 17 and 21 provides developers with enhanced security, improved performance, and the newest capabilities of the Java platform.

• Upgraded development environment: Support for Gradle 8 enables improved build automation features and performance.

Liferay now allows users to sort Custom Objects entries based on data from related objects. This enhanced functionality provides greater flexibility and control when managing complex data structures, enabling users to organize information more effectively.

Feature Status Change

It is now possible to select Date Times as a product option type, configuring purchase options for products based on date, times, time zones, and durations, allowing for the sale of time slots.