これらのアプリケーションサーバーはベンダーからのアップデートを受けれなくなったため、2024.Q3 以降からサポートが削除されます。
Wildfly 26.1 および Jboss EAP 7.4は引き続き完全にサポートされます。
Release Notes
このセクションには、DXPの機能および性能の重大な変更点に関する情報が含まれています。重大な変更点または内部コードについては、こちらのリンクをご覧ください。
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として利用可能になりました。 日付ファセット・ウィジェットは使用できなくなりました。
詳細については、検索のカスタムファセットの日付範囲と範囲集約をご参照ください。
タグフィルターウィジェットはタグをアルファベット順にソートしていましたが、お客様はより多くの用途のタグを最初に見ることを期待しているようです。私たちはこの変更が理にかなっていると考え、このウィジェットの動作を修正しました。
何が変わったのか？
以前は、一部の修正コンフリクトとすべての修正削除コンフリクトは手動で解決する必要がありました。このようなケースは、「変更のチェック」画面に表示され、解決するために手動でのユーザー操作が必要となる。 これらの変更は、パブリケーションで行われた変更でプロダクションを上書きすることで自動的に解決され、[変更の確認]画面には表示されなくなりました。
この変更はなぜ行われたのか？
以前の動作では、ユーザーは多くの種類のコンフリクトに手作業で対処する必要があり、通常、時間のかかる作業でした。この新しい動作は、パブリケーションのユーザーが必要な修正を出版できることを保証しながら、パブリケーションプロセスにおける摩擦を軽減します。
誰が影響を受けますか？
すべてのパブリケーション・ユーザーが影響を受けますが、コンフリクトの解決とコンテンツのパブリッシングを担当するユーザーに焦点が当てられています。
重大な変更をより適切に適用するには、機能または実装をどのように更新する必要がありますか?
パブリケーションのユーザーは、本番の変更を上書きする権限をより強く持つようになりました。エンドユーザーのシナリオで、修正削除のケースで人間による検証がまだ必要であることを理解している場合、インスタンス設定 > パブリケーションで修正削除の競合トグルを使用することで、以前の動作を復元できます。
何が変わったのか？
パブリケーションに「古い」というラベルを付けてユーザーがコンテンツを公開できないようにする古い機能は、デフォルトでオフになりました。
この変更はなぜ行われたのか？
ユーザーは、Liferayのアップグレード前に作成されたパブリケーションを公開できるようにしたいと考えていましたが、競合管理の改善により、これが可能かつ安全になりました。
誰が影響を受けますか？
進行中のパブリケーションを持ちながら、Liferay をアップグレードした、またはアップグレードを計画しているユーザー。
破壊的な変更をより適切に適用するには、機能または実装をどのように更新すればよいですか？
必要に応じて、インスタンス設定 > スキーマバージョンチェックの有効化の切り替えによって、この機能を有効/無効にできます。デフォルトではオフになっています。
コンテンツページのウィジェットにあった2つの設定メニューは、1つのメニューに統合されました。
非推奨機能フラグのパターン定義に従って、機能フラグはインスタンス設定の下に移動されました。
コレクションページはページ管理者から削除されました。 アップグレードパスは、機能的な変更なしに、コレクションページをコレクション表示のあるコンテンツページに置き換えます。
解決策は、ルートモデルの仮定における "制限 "のために、データモデルに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 も必要になります。