What changed?
Admins can now fully customize the permissions for the "Owner" and other roles in Publications. This includes the ability to revoke critical actions such as "Publish on Production." Previously, users who created a publication were always granted full permissions by default, including publishing rights.
Why was this change made?
This change was introduced to address a gap in the permission model that could unintentionally allow users to publish content to production—even when Sandbox mode was enabled. By enabling permission customization, we close this loophole, giving administrators better governance over content workflows. The new behavior improves system security and reduces the risk of misconfigurations, especially in environments where publishing control is critical.
Who is affected?

All publication users are affected, but the changes are focused on Admins and Publication’ Owners

How should I update my features or implementation?

No need for updates. When reviewing the permissions assigned to the "Owner" role in each publication be sure to use the new "Edit Permissions" modal.

What changed?

• Users can filter Navigation Menus by creation or modification date.

• API’s now allow retrieving navigation menus by External Reference Code, rather than only by internal IDs.

Why was this change made?

This change improves the reliability and usability of cross-site migration tools, enhances content governance with complete permission handling, and introduces stable referencing via ERCs.

Who is affected?

Developers and Site administrators requesting Navigation Menu’s via Api’s.

How should I update my features or implementation?

No changes are needed. Users may want to use External Reference Code when referencing navigation menus.

The Java EE libraries are no longer in active development. DXP has moved to the modern and evolving enterprise Java platform, Jakarta EE 10. With the migration of the system to Jakarta EE, any Java EE libraries (javax.*) are no longer compatible and must be replaced with the Jakarta EE 10 (jakarta.*) updated versions. This also breaks any 3rd party libraries that rely on Java EE packages. Libraries must be updated to a Jakarta-compatible version.

This affects any users with custom code deployed to the Liferay DXP JVM. Client Extensions are not affected since they run in an external process.

With the migration of the system to Jakarta EE, the following deprecated application servers are no longer supported:

1. Apache Tomcat 9.0.x

2. JBoss EAP 7.4

3. Wildfly 26.1

4. Weblogic 14c

Users must migrate to a Jakarta EE compatible application server:

1. Apache Tomcat 10.1.x

2. JBoss EAP 8.0

3. Wildfly 30

(Weblogic 15 has not been released, but we are monitoring its availability and plan to add support in a future DXP release).

This change gives users access to actively maintained application servers that leverage the modern Java enterprise ecosystem.

PortletMVC4Spring has migrated to a new version based on Spring 6.0 and Jakarta EE. Users must migrated their existing PortletMVC4Spring projects to version 6.x

The previous versions of PortletMVC4Spring were deprecated due to dependency on Java EE and will no longer work with 2025.Q3 release.

The current version of Liferay Faces was deprecated due to dependency on Java EE and will no longer work with 2025.Q3 release.

However, Liferay is still preparing a new version of the Liferay Faces, based on Jakarta EE 10 and Portlet 4.0, scheduled for release later this year. Since the dependencies in DXP are already migrated, it is expected that the new Faces release will be compatible with 2025.Q3

これらのアプリケーションサーバーはベンダーからのアップデートを受けれなくなったため、2024.Q3 以降からサポートが削除されます。

Wildfly 26.1 および Jboss EAP 7.4は引き続き完全にサポートされます。

Java JDK 17 および 21 Runtimeの新しいサポートにより、Java 11 は2024.Q3以降のDXPランタイムではサポートされなくなります。

Liferay Workspaceは、JDK 17 または 21でのカスタムモジュールの再コンパイルのサポートを提供します。