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

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.

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

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

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

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

何が変わったのでしょうか？

Liferay DXP 2024.Q2以降、ローカライズ可能なオブジェクトの入力フィールドのデフォルトがインスタンスの言語設定になりました。

この変更はなぜ行われたのでしょうか? 新しい動作はユーザーにとってより良いものなのでしょうか?

この変更は、一貫した言語設定を確保するために実施されました。新しい動作はユーザーにとってより良いものです:

• これは、異なる言語設定のユーザーが同じオブジェクト入力フィールドを操作する際に発生する可能性のある不一致を防ぎます。

• すべてのユーザーインタラクションにおいて統一されたエクスペリエンスを提供します。

誰が影響を受けますか?

Liferay DXP 2024.Q2より前のバージョンを使用している、またはアップグレードしているお客様は、この変更の影響を受けます。

重大な変更をより適切に採用するには、機能や実装をどのように更新すればよいでしょうか?

新しい動作に適応するために:

• ローカライズ可能なオブジェクトエントリのデフォルトの言語設定を確認してください。

• 必要に応じて、インスタンスの言語に合わせてこれらの設定を調整します。

これにより、一貫した言語デフォルトが保証され、すべてのユーザーに統一されたエクスペリエンスが提供されます。

AMBackwardsCompatibilityHtmlContentTransformerクラスは、アダプティブ・メディアが実装される前に作成されたコンテンツを管理するために、アダプティブ・メディアのリリース（～7年前）で導入されました。 このアプローチによって、当時はコストのかかるアップグレードを避けることができました。 しかし、多くの時間が経過し、新しいコンテンツがこの処理を必要としなくなったため、AM後方互換HTMLコンテンツ変換器をデフォルトで無効にしています。

この変更の主な理由はパフォーマンスである。コンテンツ・トランスフォーマーは、特にトラフィックが多い場合、CPUリソースを大幅に消費する可能性があります。

必要に応じて、インスタンス設定 ＞ アダプティブ・メディア でコンテンツ・トランスファーを有効にできます。

Webコンテンツの編集時に、「下書きとして保存」と「キャンセル」オプションが表示されなくなりました。その代わりに内容は自動的に下書きとして保存されます。
自動保存の実装により、ユーザーはコンテンツの編集中に進行状況が失われる心配がなくなりました。自動保存により、すべての変更がバックグラウンドで継続的に保存されるため、予期せぬ中断によるデータ損失のリスクが軽減され、安心感が得られます。

Java JDK 17 および 21 への移行に伴い、DXPの java.locale.providers 設定がデフォルト値に戻されました。

以前は、JREがデフォルトのプロバイダであったため、DXPとPortalはJava 8と11の一貫したロケール動作を提供するために java.locale.providers=JRE,COMPAT,CLDR の設定を推奨して配布されていました。 Java 17および21では、JREは非推奨となり、CLDRロケール・プロバイダがデフォルトおよび推奨プロバイダになりました。 Oracleからの 詳細情報 をご参照ください。

新しい推奨値は java.locale.providers=CLDR,COMPAT で、これは新しいJVMのデフォルトです。 2024.Q4用のLiferay Tomcatバンドルは、デフォルトを使用しているため、このJVMプロパティが設定されていない状態で出荷されます。

このデフォルトプロバイダーの変更により、システム内の一部のロケール情報が変更された書式で表示される可能性があります。 例えば、日付と時刻の表示が、以前は「9/12/24 9:10 PM」と表示されていましたが、現在は「9/12/24, 9:10 PM」と表示されていることがあります。これは、最新の言語標準に対応した最新のJavaロケール・プロバイダに移行することで期待される結果です。

一部の404リダイレクトが404エラーページではなく、前のページに戻る原因となっていたバグを修正します。

ユーザーが前のページにリダイレクトされることに依存していた実装があれば、404ページへの新しいリダイレクトを考慮して更新する必要があるかもしれません。

これは、BETA FF期間中のデータセットのための変更です。

• このエピック以前にデータセットを作成した人は、データセットマネージャーでデータセットを見ることができなくなります。

• データセット・フラグメント構成では、オプションとして以前のデータセットが表示されなくなりました。

• ページ上に配置されたデータセット・フラグメントは何も表示されなくなりました。

• データセット・ビューは削除された。今後、データセットはビューしか持ちません。

• 新しいデータセットのエンドポイントが利用可能になり、datas-et-adminで動作するようになりました（例：http://localhost:8080/o/api?endpoint=http://localhost:8080/o/data-set-admin/data-sets/openapi.json）。

• すべてのデータセット・エンドポイントはまだ利用可能で、data-set-managerの下で動作していますが、データセット・マネージャーやフロントエンド・データセットでは使用されていません。 この変更前に作成されたデータセットの情報は、データセットに保存されます。（例：http://localhost:8080/o/api?endpoint=http://localhost:8080/o/data-set-manager/data-sets/openapi.json）

詳細情報: LPD-29979

• 何が変わったのでしょうか？
  フラグメントからのJavascriptは、関数にコードを埋め込む代わりに、<script> of type moduleを使用してページに含まれるようになりました。

• なぜこの変更が行われたのですか?
  javascriptモジュールで利用可能なすべての機能を活用すべく変更されました: JavaScript modules - JavaScript | MDN
  例: import文を使う機能です。

• 何が影響を受けますか?
  モジュール型のタグ<script> で直接サポートされていないコード
  例:

  • return 関数のスコープ外のステートメントを返す。

  • 自動変数宣言, 例: myVariable = 'value'

• 重大な変更をより適切に採用するには、機能や実装をどのように更新すればよいでしょうか?
  コードの移行はとても簡単です。return文を削除し、変数宣言には変数名の横に let か constを使用するだけです。const myVariable = 'value'
   一時的な回避策として（すぐに削除されると思われますが）、この機能にdisableを追加しました。 インスタンス設定 > ページフラグメント > フラグメントJavascript のチェックボックスを無効にしてください。

コレクションを追加するメソッドを変更し、作成時にERCを指定できるようにした。 これらのサービスを使用しているJavaコードをお持ちのお客様は、呼び出し時にERC（またはNull）を指定するように修正する必要があります。

2024.Q1のLPS-153839のDeveloper FFで導入されたDate Facetウィジェットの機能が、カスタムファセットに統合され、GAとして利用可能になりました。 日付ファセット・ウィジェットは使用できなくなりました。

詳細については、検索のカスタムファセットの日付範囲と範囲集約をご参照ください。

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

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

• 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) の機能フラグが必要です。