非推奨機能フラグのパターン定義に従って、機能フラグはインスタンス設定の下に移動されました。

コレクションページはページ管理者から削除されました。 アップグレードパスは、機能的な変更なしに、コレクションページをコレクション表示のあるコンテンツページに置き換えます。

• 解決策は、ルートモデルの仮定における "制限 "のために、データモデルに2つの破壊的な変更を導入することです。

  • Data Set と Data Set Actionをつなぐ関係は、アクションの種類によって2つありました。今あるのは1つのみです。

  • Data Set Actionオブジェクト定義のtypeフィールドが変更されました。これで、アクションのタイプ（アイテム、作成、一括）が保存されます。 旧typeは targetフィールドに移動するようになりました。

• その結果、以前に保存したデータセットのアクションはDSMで管理できなくなり、フラグメントもそれを見つけることができなくなります。

JSPのシステム処理を簡素化し、パフォーマンスを向上させるために、2025.Q1 では、以前は work.dir.override.enabled=true というプロパティによって有効になっていたオプション設定が削除されました。 JSPは常にOSGiバンドル内に留まるようになりました。 この機能は、パフォーマンスが犠牲になるため、デフォルトではすでに無効になっています。

2024.Q2 リリース以降、Portalのランタイムには Java 17 または 21 がすでに必要ですが、ソースコードはJava 8でもコンパイルできました。2025.Q1 リリースでは、コンパイルに Java 17 または 21 も必要になります。

ヘッドレス APIを使用してテキスト・フィールドに対してGETを実行し、その結果コンテンツが空になった場合、出力がスキップされる代わりに ”” が返されます。この変更により、各ユーザーが情報を使って何をするか、より柔軟に決めることができるようになりました。

ユーザーは、この変更に対応するために、テキストフィールドに対するすべてのGETリクエストを見直してください。

現在、ユーザーが任意のエンティティをインポートするためにBatchを呼び出すと、返されるエラーはRest APIへの通常の呼び出しとは異なるストラクチャを持ちます。具体的には、「failedItems」情報に関連する構造が異なっています。

この変更により、ユーザーはどのエンドポイントを使用していても同じストラクチャ化された情報を持つことになるので、エラーのマッチングやUIでの表示はよりシンプルになります。

主な変更点:

現在のストラクチャ:

"failedItems": [ 
{ "item": "{\"properties\": {\"field1\": 4, \"field2\": 5}}", 
  "itemIndex": 1, 
  "message": "com.liferay.portal.kernel.exception.ModelListenerException: com.liferay.object.exception.ObjectValidationRuleEngineException: Field 1 must be greater than,Field 2 must be greater than 5" } 
  ]

新しいストラクチャ:

"failedItems" : [ {
    "item" : "{\"properties\": {\"field1\": 4, \"field2\": 5}}",
    "itemIndex" : 1,
    "message" : "[{\"objectFieldName\":\"field1\",\"errorMessage\":\"Field 1 must be greater than\"},{\"objectFieldName\":\"field2\",\"errorMessage\":\"Field 2 must be greater than 5\"}]"
  } 
  ]

• 「更新」権限の付与: ロールに「更新」権限を付与することで、ユーザはフォルダの名前や説明などのプロパティを編集できるようになります。

• 「詳細な更新」権限の付与: ロールに 「詳細な更新」権限を付与することで、ユーザーはフォルダに関連付けられたワークフローを更新できます。名前や説明フィールドなどのフォルダのプロパティは、無効のままでの編集はできません。

• Webコンテンツまたはフォルダを購読しているユーザーは、ワークフローのレビュープロセスに直接関与していない限り、保留状態のアセットに関する通知を受信しません。

• この変更は、ドキュメントとメディアの現在の動作に合わせるためのものです。

ユーザーがAnalytics Cloudで削除されると、永久に削除される前にまず抑制されます。 その結果、ユーザーごとに2つのリクエスト（抑制と削除）が表示されます。

以前は、各ユーザーの削除には2つの別々のリクエストが発生していました。 現在では、すべてのユーザーが1つの抑制および削除リクエストにグループ化され、リクエスト数が減少しています。 たとえば、各リクエストには、ユーザーごとに個別のリクエストを生成する代わりに、影響を受けるすべてのメールアドレスのリストが含まれるようになりました。

Analytics Cloud > Settings > Data Control & Privacy > Request Logで削除ログを確認できます。

何が変わったのか？
新しい一括操作機能により、パブリケーション内の複数の変更を選択して管理できます。 ユーザーは、管理バーから一括して変更を移動または破棄できるようになった。 これにより、大規模なパブリケーションの管理が簡素化される。

なぜこのような変更がなされたのか？
以前は、ユーザーはそれぞれの変更を個別に管理しなければならず、時間がかかっていた。 この変更により、ユーザーの効率が向上し、管理負担が軽減され、大規模なパブリケーションに対してよりスケーラブルなプラットフォームとなった。

新しい行動はユーザーにとって良いことなのか？
時間と労力を大幅に節約し、複数の変更を迅速に管理することが容易になる。 この結果、大量の変更を処理する際に、よりスムーズで迅速なユーザーエクスペリエンスが実現します。

誰が影響を受けるのか？
大規模なパブリケーションを管理したり、複数の変更を処理する必要があるユーザーは、このアップデートの恩恵を受けるだろう。 頻繁に変更箇所を移動したり、破棄したりするユーザーのプロセスを効率化します。

どのように自分の機能や実装を更新すれば、より良いブレークチェンジを採用できるのか？
必要に応じて、この機能は、インスタンス設定 > 機能フラグ > feature.flag.LPS-171364=true または パブリケーションの一括アクション (LPD-20183) の機能フラグで有効/無効にできます。

何が変わったのか？
レビュー変更画面にプログレスバーが追加され、公開プロセス中にリアルタイムで視覚的なフィードバックが得られるようになりました。 ユーザーは、公開が開始されるのを待っている間、プログレスバーが表示され、公開プロセスの残り時間を知ることができます。

なぜこのような変更がなされたのか？
以前は、公開プロセスにかかる時間をユーザーが視覚的に示すことはできませんでした。 この変更は、透明性を提供することによって、ユーザーエクスペリエンスを向上させ、ユーザーの期待をよりよく管理できるようになります。

新しい行動はユーザーにとって良いことなのか？
新しいプログレスバーは、明確でリアルタイムのフィードバックを提供することで、ユーザーの満足度を高めます。 これにより、ユーザーはパブリケーションスのケジュールを把握しやすくなり、プロセス中の不安を軽減できます。

誰が影響を受けるのか？
すべてのパブリケーション利用者が影響を受けますが、これまで待ち時間が不明瞭であった大規模なパブリケーションや複雑なパブリケーションを扱う利用者に焦点が当てられています。

どのように自分の機能や実装を更新すれば、より良い重大な変更点を採用できるのか？
現在のプロセスに変更は必要ありません。

何が変わったのか？
パブリケーションのサイズ分類がレビューの変更画面に表示されるようになり、パブリケーションのサイズに基づいてLight、Medium、Largeに分類されるようになりました。 ユーザーが分類の上にカーソルを置くと、ポップオーバーで説明が表示され、パブリケーションサイズがパブリケーションのプロセスに与える潜在的な影響について知ることができます。

なぜこのような変更がなされたのか？
この変更により、ユーザーはパブリケーションの規模を把握しやすくなり、パブリケーションのプロセスをより適切に計画できるようになります。 これは、大きなパブリケーションにより多くの時間を割り当てるようユーザーに促すことで、パフォーマンスの問題を防ぎ、競合を減らすことを目的としています。

新しい行動はユーザーにとって良いことなのか？
この新しい分類は、パブリケーションの複雑さをより明確に把握し、ユーザーが予期せぬ遅延を避けるのに役立つ。 また、ワークフローを積極的に管理することで、よりスムーズな公開プロセスを実現することができます。

誰が影響を受けるのか？
すべてのパブリケーションユーザーが影響を受けますが、複数の変更に対応するユーザーや、Webサイトを公開する際に達成しなければならない締め切りがあるユーザーにより重点を置いています。

どのように自分の機能や実装を更新すれば、より良い重大な変更点を採用できるのか？
必要に応じて、この機能を完全に動作させるには、インスタンス設定 > 機能フラグ > パブリケーションツールバーの追加コンテキスト (LPD-20556) の機能フラグが必要です。

フラグメントは、コレクションディスプレイの最初のアイテムにのみドロップしてマッピングできます。

コレクションページがページ管理者から削除されました。

ドキュメンテーション: LRDOCS-14626: Documentation LPD-45659 - Remove Collection Pages from page administratorClosed

ページのSEO設定は、DDMから標準フォームに移動しました。

（ページの）レイアウトの permissions.view.dynamic.inheritance プロパティが変更されました。他のすべてのモデルでプロパティがどのように機能するかに合わせるためのロジック:

1. 現在はVIEWアクションにのみ適用されます。

2. 現在は制限されています: あるページにVIEWアクセスするためには、ユーザーはその特定のページとそのすべての祖先ページのVIEW権限を持っていなければなりません。

LRDOCS-15042

Ehcache 2.xは、Javaコミュニティによって公式にメンテナンスされなくなりました。DXPの内部キャッシュをEhcache 3.10.8に移行しました。

つまり、既存のehcache設定 xml ファイルは直接互換性がなく、新しい3.x環境でエラーや予期せぬ動作を引き起こす可能性が高いということです。 ユーザーはこれらの設定を見直し、新しい3.xスキーマに従って書き換える必要があります。

AMDローダーは削除されました。 Liferay DXPはJavaScriptの公式標準モジュールシステムであるESMを公式にサポートしていますが、AMDはサードパーティ製のソリューションでした。 ESMを採用することで、製品はその言語固有の能力と将来の方向性に合致します。 最近のブラウザはESMをネイティブにサポートしており、トランスパイルや追加のローダーなしで直接使用できます。 これにより、バンドルサイズの縮小、初期ページロードの高速化、開発ワークフローの簡素化が可能になります。

amd-loader を使用しているユーザーは、Liferay.loader に移行する必要があります。詳細は リンク をご参照ください。

The "Warehouse" field has been removed from the Shipping Option's details panel.

This field was previously available as a selection field within the shipping option configuration, but it is crucial to understand that it was purely informational and did not enforce any actual warehouse restrictions or logistics.

The "Warehouse" field was identified as a source of potential confusion for administrators. Its presence, despite being purely descriptive, could lead to the incorrect assumption that it played a role in applying warehouse restrictions to a shipping option. To ensure clarity and prevent any misleading interpretations, we have decided to remove this field entirely.

Important Note for Administrators: If you used this field for metadata, this information will no longer be visible. We strongly recommend transferring any critical metadata to an alternative location before upgrading to avoid loss. This change does not impact actual warehouse configurations or shipping logic.

This portal-ext property was to Instance/System settings so that the property could be controlled during runtime. Users will need to reconfigure portal if they are currently using this property.

See https://github.com/liferay/liferay-portal/commit/0b2ee06d7ee20972bc8ebd84e2c1c10fb9a41763

What changed?
With the introduction of customizable publication-level permissions, all permissions, including publishing to production, can be changed by an admin or a user with the appropriate "Manage Permissions" capability.

Why was this change made?
Previously, Owners were automatically given the ability to publish content to production, which led to unintentional production changes, especially in environments using Sandbox mode or implementing stricter governance policies. This behavior was inconsistent with customer expectations and Liferay’s broader permission model.

Who is affected?
How should I update my features or implementation?
No need for Updates. You may want to use the new "Permissions" on Publication Settings section to "Edit Permissions" if needed.

What changed?
A new warning message now appears when "Sandbox Only" mode is enabled but publication Owners retain permission to publish. This does not change the behavior of Sandbox mode but introduces a new UI-level validation to prevent unwanted changes.

Why was this change made?
This message prompts admins to review permission settings and avoid potential production changes made in error. The goal is to support secure sandbox and prevent publishing mistakes by making permissions more transparent.

Who is affected?

Publication users with enough access to configure Publications and enable Sandbox mode.

How should I update my features or implementation?

No need for Updates. When enabling Sandbox Only mode, look for the new warning message and use the "Edit Permissions" option to review Owner permissions.

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でのカスタムモジュールの再コンパイルのサポートを提供します。