This section contains information about breaking changes in out-of-the-box DXP features and capabilities. For breaking changes or internal code, please check this link.
Clearing active facet selections on new searches
After searching with a keyword and selecting facets, searching with a new keyword (in either using the header Search Bar or any Search Bar widget instance on a page) will clear all active facet selections.
The old behavior can be enabled via the Search Options widget by ticking Retain Facet Selections Across Searches option.
com.liferay.portal.kernel.util.RemotePreference API is removed
This affects any custom code using Liferay’s API methods User.getRemotePreference(String) and User.getRemotePreferences().
The API supporting logic has to collect and hold cookies in User object, causing unnecessary CPU and memory overhead. These methods were just a convenient shortcut to get the user's current request's cookies with REMOTE_PREFERENCE_ name prefix. The same logic can be done by directly getting necessary cookies from request.
Allow users to set the localization for custom objects
What changed? Currently, the translatable object fields use the configured languageId from the user. With this change, it is going to use the preferred Locale given by the DTOConverterContext instead.
Why was this change made? This change is needed in order to return the appropriate translatable object field values for the language setting in the Accept-Language header.
Who is affected? Every user that calls the translatable object fields.
How should I update my features or implementation to better adopt the breaking change? Adding or removing (depends on the cases) the Accept-Language header.
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.
Better default configuration of the Menu Display widget when placed on a Page Template
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.
Private Cache-Control header for DM file download with guest permissions
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:
Duplicated names when selecting object definitions/entities with the same name
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.
Update our external API to include the new impressionMadeMetric
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.
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?
Full Field Visibility in the Data Tab for Content Reviews
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?
Export and Import of Site-Scoped Settings via the Configuration Headless API
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?
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.
Object Inheritance – Relationship Field Behavior Updated
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.
Object Entries with Related assets now require VIEW permissions to ADD Object Entry
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.
DXP AWS S3 Store connector migrated to AWS SDK for Java 2.0
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.
Breaking Changes:
NTLM Proxy Users: NTLM proxy authentication to connect to AWS will no longer work. Users will need to switch to username/password authentication or use another proxy solution.
Custom Signer Override: If you relied on signerOverride for compatibility with older S3-compatible services, you'll need to verify compatibility with SDK v2's default signing behavior.
Explicit HTTP Protocol: If you were forcing HTTP (non-HTTPS) connections via connectionProtocol, this setting is now ignored. The SDK will determine protocol based on your endpoint configuration.
In Summary, the following configuration keys are now for IBM only, they are no longer used by AWS
signerOverride
connectionProtocol
ntlmProxyDomain
ntlmProxyWorkstation
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.
Data Cleanup and Removal moved to Server Administration
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.
These can now be executed manually and on-demand from Control Panel → Server Administration → Resources → System Cleanup Actions (or Module Cleanup Actions). The names and tooltips for each of these have been updated to provide additional information on what each action does.
The following configuration files for these have been removed in favor of the Server Administration experience.
Default behavior changes to the Database Upgrade Tool
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.
The default maximum heap memory has been doubled from 2048 MB to 4096 MB. The previous default was insufficient for any large upgrades and could cause out-of-memory errors. The new default provides additional headroom and improves upgrade stability.
Custom memory limits can still be set using the --jvm-opts parameter.
Even larger limits may be needed depending on the database size.
Recent DXP versions ship with a simpler tomcat directory name instead of including the version number (such as tomcat-10.1.43). This applies to both bundled Tomcat releases and Docker images. The default in app-server.properties has been updated to match this change. This reduces the need for manual property management when upgrading modern DXP installations.
The interactive setup now validates inputs as they are entered, catching problems before the upgrade starts. Previously, only the application server type and database type were validated, allowing invalid values to proceed until failures occurred later in the process. This approach catches configuration mistakes early instead of allowing them to cause failures during upgrade execution. The following inputs are now validated:
Directory paths: When paths are entered for Liferay home, application server directory, extra libraries, global library, or portal directory, the tool verifies they exist. Invalid paths trigger an error message explaining the issue, and the prompt repeats.
Database host: The tool checks if the database hostname can be resolved via DNS. Resolution failures result in an error message with details.
Database port: Port numbers are validated to ensure they fall within the valid range (0-65535). Invalid ports are rejected immediately with an error.
The tool now reads existing database configuration from portal-ext.properties instead of requiring re-entry. It can still be overridden by portal-upgrade-ext.properties.
Default JVM parameters are automatically applied, in addition to custom parameters from --jvm-opts. The following are applied unless explicitly changed by the user:
-Dfile.encoding=UTF8
-Duser.country=US
-Duser.language=en
-Duser.timezone=GMT
-Xmx4096m
To improve database upgrade performance, database connections are now automatically configured with batch insert optimization parameters, removing the need for manual JDBC URL configuration for the upgrade. User defined parameters are still preserved.
PostgreSQL: Adds reWriteBatchedInserts=true to enable batch insert optimization
MySQL/MariaDB: Adds rewriteBatchedStatements=true to enable batch statement rewriting
SQL Server: Adds useBulkCopyForBatchInsert=true to enable bulk copy for batch operation
The upgrade tool now uses a single configuration file for all upgrade settings. All properties are set from portal-upgrade-ext.properties. The portal-upgrade-database.properties is now deprecated and ignored.
The default application server directory paths in both the app-server.properties template have been updated to use explicit relative path notation to reduce confusion about the upgrade file paths.
/bin → ./bin
/lib → ./lib
/webapps/ROOT → ./webapps/ROOT
/WEB-INF/... → ./WEB-INF/...
The upgrade tool's interactive wizard now uses PostgreSQL as the default database. This change reflects PostgreSQL's widespread adoption and recommended usage for Liferay DXP. Users can still select any supported database by entering a different value at the prompt.
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 following features will be removed in the upcoming Liferay Developer Studio (LDS) release:
Liferay Upgrade Planner: Feature to aid developers in migrating their code from older versions of Liferay to newer versions.
Liferay IDE AlloyUI : Development tooling for the AlloyUI framework.
Liferay IDE XML Search: The XPath-based search tab in the Search menu.
Why is this happening? The dependencies for these features were hosted in an external repository that we no longer have access to. This is blocking us from building and releasing new versions of LDS. Removing these features is the only path forward to unblock the release of new LDS versions and ensure we can continue delivering updates to our users.
What this means for our users? While these features provided value in certain contexts, they haven't been maintained in some time and may no longer provide a quality experience for our customers. Several alternatives are available in order to ensure existing workflows aren't interrupted:
The upgradeSourceCode command in Blade is actively maintained and offers robust code upgrade automation to handle migrations to newer Liferay versions.
Liferay IDE AlloyUI
For AlloyUI development, the built-in features provided by the Web Tools Platform should provide similar functionality OOTB, though additional configurations may be needed to enable autocomplete and syntax highlighting for AlloyUI. Third-party plugins such as Eclipse Wild Web Developer are also available on the Eclipse Marketplace which offer robust JavaScript support.
If users need XPath-based searching functionality for XML files, Eclipse Marketplace has additional plugins available such as Eclipse XPath Evaluation Plugin.
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.
SSE transport is no longer supported by the MCP Server
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.
Elasticsearch 7 EOL and Removal from the Supported Search Engines
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.
Enable easy access to Edit Page During Review in Publications
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:
Non-content pages (Panel, Page Set, URL, Embedded, Link to Page) → Configuration screen
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.
How should I update my features or implementation?
Remove the Commerce’s Countries menu item from the Commerce Menu
Liferay’s Countries feature was migrated from being a Commerce feature to a DXP feature, thus Commerce’s Countries page was removed. Users that manage Countries will now be able to manage them through the Countries Management page under the Control Panel.
Content is no longer classified as translated solely upon the translation of its title. Now, when a user translates any field, not just the title, but also the content status changes to "Translating". It will only be considered translated when all fields have been translated.
Publishing or saving content for the first time requires an additional step to confirm or manage permissions
To bolster permissions management and elevate user awareness concerning content, users will now be prompted to confirm permissions during the initial publishing or saving process, requiring an additional click. Subsequent saving or publishing actions will not require this confirmation.
When the default site has a Virtual Host defined, it will not be added to the company's XML sitemap
A new SEO menu has been added in Instance Settings with an item selector to include specific Sites or all of them, in the sitemap of the Company through the Company's Virtual Host, and the default site cannot be deleted from the list. If the default site has a Virtual Host defined, it will not be added to the company's XML sitemap although listed in the configuration.
Users are currently presented with a group of features that are not relevant in the configuration page for Utility Pages. These non-applicable features have been removed while preserving the essential HTML Title, HTML Description, and SEO configuration elements.
The name of the reserved variable ID has always referred to the article ID so it has been changed to: Article ID. A new ID variable has been added that refers to the ID.
Sites are not browsable for Guests in Breadcrumb portlet
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.
Default value of membership management is disabled
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.
This website uses cookies and similar tools, some of which are provided by third parties (together “tools”). These tools enable us and the third parties to access and record certain user-related and activity data and to track your interactions with this website. These tools and the informationcollected are used to operate and secure this website, enhance performance, enable certain website features and functionality, analyze and improve website performance, and personalize user experience.
If you click “Accept All”, you allow the deployment of all these tools and collection of the information by us and the third parties for all these purposes.
If you click “Decline All” your IP address and other information may still be collected but only by tools (including third party tools) that are necessary to operate, secure and enable default website features and functionalities. Review and change your preferences by clicking the “Configurations” at any time.
Visit our Privacy Policy