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.

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.

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.

Data Set Manager lets from now to map Array structures, so a given cell of a Data Set can show list of values, for example to list the roles of a user or the tags of a product.

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.

When the users are facing a Frontend Data Set the items can show actions to interact with them that are set in the Data Set Manager. From now own, when the user navigates to a destination URL through an item or creation action, the current URL is added to the destination page, so the user can return to the Data Set after performing the action seamlessly.

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

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

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

Users can now create picklists beginning with capital letters. One key feature is that now users will be able to filter by Active and Inactive values.

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.

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.

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.

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.