From now on, the segments tab for the Administrator role will no longer be displayed in the assignees' tab. Assigning the Administrator role through segments is not allowed.
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.
The guest role from the role selector was disabled since it is not possible for it to work. |
The configuration sections in Utility Pages are not enabled, as the other pages, due to their use being more restricted. The implementation of these settings should occur by analyzing each case.
As mentioned in the new features section the following properties having been transformed in configurations, so they are no longer available in the properties files:
session.timeout.auto.extendsession.timeout.auto.extend.offset
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:
With the upgrade of the client libraries, the minimum compatible Elasticsearch minor version shits to 7.17.x.
When the server is lower than the expected version, the DXP won't start-up, but fail with an error in the DXP console:
10-22 10:45:22.619 ERROR [main][ElasticsearchSearchEngine:375] Elasticsearch node es-node-1 does not meet the minimum version requirement of 7.17
The self bootstraping style *SearchRegistrar has been changed to service collecting of ModelSearchConfigurator.
Indexer registration code for custom entities has to be adjusted to become an OSGi service of type ModelSearchConfiguratorand to move all previous ModelSearchConfigurator setter call parameter as corresponding ModelSearchConfigurator getter return value.
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.
Until now, when we had 2 ItemSelectorViews with the same name, only one of them was taken into account when rendering. This is more noticeable now with the CMS where we have object definitions like Blogs. In order to allow the users to select all the object definitions and legacy entities, now they appear duplicated when they have the same name.
We recently updated our tracking logic within documents, replacing the previewed event with a new event: impressionMade. To align with this change, we also updated our current API to include a new metric — impressionMadeMetric — which consolidates impressions by summing both the new impressionMade events and the legacy previewed events.
What changed?
The Display tab in the Review Changes screen now renders Display Page Templates and content that uses those templates (e.g., Web Content Articles, Blog Entries). Previously, these were not previewable — the Display tab was either empty or disabled for such content.
Why was this change made?
This change allows content reviewers to see the real end-user layout before publication. It significantly improves quality assurance by reducing publishing errors and increases confidence that the final layout will match expectations — especially for structured content and enterprise use cases (e.g., FHLBNY). This change improves usability and eliminates a gap in the review process that could result in visual inconsistencies post-publication.
How should I update my features or implementation?
No changes are needed.
What changed?
The Data tab in the Review Changes screen for Web Content Articles now displays all editable fields, including those created via custom structures. It also shows field labels and values exactly as defined by content creators.
Why was this change made?
Previously, only a subset of fields was shown, which often led to missed content changes during the review process. This update makes it easier to catch all modifications, especially in highly customized structures — enhancing accuracy and trust in the publishing process.
How should I update my features or implementation?
No changes are needed.
What Changed?
The Configuration Headless API now exposes and manages site-scoped configurations that were previously unavailable through export/import operations. During import, existing configurations for a site are now overridden with the incoming configuration data based on groupId scope matching.
Why Was This Change Made?
This change ensures that site migrations are more complete and consistent, including configuration data that was previously missing.
How should I update my features or implementation?
No changes are needed.
The results of a search haven’t to be shown the content of a fragment is within a collection display and is not indexed.
The change was already done for text editable, since the button fragment have to allow text only, and it was forgotten for the link editable.
The system-wide Mail Settings for DXP were migrated to use the standard system configuration framework.
The system options in Server Administration > Mail were moved to System Settings > Email > Virtual Instance Scope > Mail Settings
The existing settings from previous releases will be automatically migrated during the database upgrade process.
The following portal properties were removed since they are now defined by configuration properties:
LIST OF PROPERTIES
Following standard configuration patterns, Instance Settings > Email > Mail Settings will have default values inherited from the System Settings. The administrator for Portal Instances can now view the default values, override, or reset to default.
Please refer to Configuring Mail - Liferay Official Documentation for additional details.
The Object Inheritance feature has been updated to support more flexible scenarios, which introduces changes to the previous behavior:
Child definitions can now be associated with multiple parent definitions.
Previously, a child could only inherit from a single parent.Child entries can now exist without a parent (standalone entries).
Before this change, every child entry was required to belong to a parent.The relationship field is no longer mandatory at the object-definition level.
Previously, the relationship field was always required when inheritance was enabled.
Now, it becomes mandatory only when the entry is created in the context of a parent.Permission and configuration inheritance now depends on whether the child entry has a parent.
Standalone entries no longer inherit permissions or configuration from a root object.
At the LPD-46627: Enhancing SAML to be able to Sync User GroupsClosed story we modified the SAML userGroups membership management according to the portal’s standard way. With that we introduced a namespace for the attribute which seems causing inconveniences to customers, described in the LPD-66611: userGroups Attribute Name Changed to membership:userGroups, Breaking Liferay IdP IntegrationsClosed bug ticket.
When users have an object entry related to another system object entry, users now need the VIEW resource permission of the related entry in order to add the object entry.
This change was made to enforce data integrity standards across DXP covering potential security breaches our users could encounter. This will affect all object admins modeling object definitions related to the following asset types
Accounts
Organizations
Picklists
Postal Addresses
Roles
When object entries are related to an asset in the aforementioned list, users must now have the VIEW resource permission on the related asset in order to ADD the object entry. This also applies to users who are trying to import an object entry with a related asset from the list.
The following features will be removed in the upcoming Liferay Developer Studio (LDS) release:
Why is this happening? What this means for our users?
Note: Developers still requiring these features can remain on their current version of LDS until they have completed their code migration or AlloyUI related tasks. |
Blade 8.0 was released to account for the new AI Rules Files. This version of Blade will generate Liferay Workspaces that are not compatible with running Gradle tasks using Java 8. If users need to use Java 8 to run Gradle tasks, they will need to downgrade their version of the Workspace Gradle plugin to version 14.0.1 or below in the generated Workspace's settings.gradle file.
The official AWS SDK for Java 1.x went End-of-Life on 12/31/2025. The AWS SDK for Java 2.0 is the actively maintained solution for connecting to AWS with our Java platform. We have migrated our Amazon AWS S3 store connector to use SDK for Java version 2.0.
No new configuration keys added for AWS SDK v2 and Liferay still uses a single S3 configuration for both IBM S3 store and AWS S3 store. |
In Previous releases, legacy data and module cleanup actions were triggered from configurations in System Settings > Upgrades > Data Cleanup (or Data Removal). These actions are important to improve performance, and improve long term system stability, and lighten the load during a DXP upgrade. We have brought some additional clarity and visibility to these system maintenance actions by moving them to Server Administration.
|
Based on feedback from our users, we have made some changes to the default behavior of the Database Upgrade Tool to improve usability and performance of the upgrade process.
|
At the end of January we have detected that Gemini rejected our requests. We found out that the way to solve it is by migrating SSE to StreamableHTTP transport because SSE is already deprecated. So SSE is no longer supported by the MCP Server.
What changed?The Edit and Edit in P1 actions in the Publications review screen now redirect users to the appropriate editing experience, depending on the page type:
Previously, users were often redirected to configuration screens even when they needed to edit layout or content. Why was this change made?Reviewers frequently need to make small fixes while reviewing changes. Sending users to the wrong screen slowed down reviews and increased frustration. This update aligns the edit action with user intent, allowing faster corrections and keeping users inside the Publications workflow. No changes are required. |
As it was communicated in 2025, Elasticsearch 7 has reached end-of-life on Jan 15, 2026 and is no longer available as a supported search engine for Liferay DXP. 2026.Q1 ships with a native Elasticsearch 8 connector as the default, bundled integration allowing to operate Liferay with Elasticsearch 8.19.
Deployments currently operating Liferay DXP with Elasticsearch 7 have to upgrade their Elastic stack to Elasticsearch 8.19 before upgrading Liferay DXP to 2026.Q1. Learn more under the Native Elasticsearch 8 entry in this Release Notes.
|