|
Release Notes
このセクションには、DXPの機能および性能の重大な変更点に関する情報が含まれています。重大な変更点または内部コードについては、こちらのリンクをご覧ください。
現在、ユーザーが任意のエンティティをインポートするために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\"}]"
}
]
解決策は、ルートモデルの仮定における "制限 "のために、データモデルに2つの破壊的な変更を導入することです。
Data SetとData Set Actionをつなぐ関係は、アクションの種類によって2つありました。今あるのは1つのみです。Data Set Actionオブジェクト定義のtypeフィールドが変更されました。これで、アクションのタイプ（アイテム、作成、一括）が保存されます。 旧typeはtargetフィールドに移動するようになりました。
その結果、以前に保存したデータセットのアクションはDSMで管理できなくなり、フラグメントもそれを見つけることができなくなります。
ヘッドレス APIを使用してテキスト・フィールドに対してGETを実行し、その結果コンテンツが空になった場合、出力がスキップされる代わりに ”” が返されます。この変更により、各ユーザーが情報を使って何をするか、より柔軟に決めることができるようになりました。
ユーザーは、この変更に対応するために、テキストフィールドに対するすべてのGETリクエストを見直してください。
タグフィルターウィジェットはタグをアルファベット順にソートしていましたが、お客様はより多くの用途のタグを最初に見ることを期待しているようです。私たちはこの変更が理にかなっていると考え、このウィジェットの動作を修正しました。
2024.Q2 リリース以降、Portalのランタイムには Java 17 または 21 がすでに必要ですが、ソースコードはJava 8でもコンパイルできました。2025.Q1 リリースでは、コンパイルに Java 17 または 21 も必要になります。
非推奨機能フラグのパターン定義に従って、機能フラグはインスタンス設定の下に移動されました。
JSPのシステム処理を簡素化し、パフォーマンスを向上させるために、2025.Q1 では、以前は work.dir.override.enabled=true というプロパティによって有効になっていたオプション設定が削除されました。 JSPは常にOSGiバンドル内に留まるようになりました。 この機能は、パフォーマンスが犠牲になるため、デフォルトではすでに無効になっています。
コンテンツページのウィジェットにあった2つの設定メニューは、1つのメニューに統合されました。
コレクションページはページ管理者から削除されました。 アップグレードパスは、機能的な変更なしに、コレクションページをコレクション表示のあるコンテンツページに置き換えます。
何が変わったのか？
パブリケーションに「古い」というラベルを付けてユーザーがコンテンツを公開できないようにする古い機能は、デフォルトでオフになりました。
この変更はなぜ行われたのか？
ユーザーは、Liferayのアップグレード前に作成されたパブリケーションを公開できるようにしたいと考えていましたが、競合管理の改善により、これが可能かつ安全になりました。
誰が影響を受けますか？
進行中のパブリケーションを持ちながら、Liferay をアップグレードした、またはアップグレードを計画しているユーザー。
破壊的な変更をより適切に適用するには、機能または実装をどのように更新すればよいですか？
必要に応じて、インスタンス設定 > スキーマバージョンチェックの有効化の切り替えによって、この機能を有効/無効にできます。デフォルトではオフになっています。
何が変わったのか？
以前は、一部の修正コンフリクトとすべての修正削除コンフリクトは手動で解決する必要がありました。このようなケースは、「変更のチェック」画面に表示され、解決するために手動でのユーザー操作が必要となる。 これらの変更は、パブリケーションで行われた変更でプロダクションを上書きすることで自動的に解決され、[変更の確認]画面には表示されなくなりました。
この変更はなぜ行われたのか？
以前の動作では、ユーザーは多くの種類のコンフリクトに手作業で対処する必要があり、通常、時間のかかる作業でした。この新しい動作は、パブリケーションのユーザーが必要な修正を出版できることを保証しながら、パブリケーションプロセスにおける摩擦を軽減します。
誰が影響を受けますか？
すべてのパブリケーション・ユーザーが影響を受けますが、コンフリクトの解決とコンテンツのパブリッシングを担当するユーザーに焦点が当てられています。
重大な変更をより適切に適用するには、機能または実装をどのように更新する必要がありますか?
パブリケーションのユーザーは、本番の変更を上書きする権限をより強く持つようになりました。エンドユーザーのシナリオで、修正削除のケースで人間による検証がまだ必要であることを理解している場合、インスタンス設定 > パブリケーションで修正削除の競合トグルを使用することで、以前の動作を復元できます。