コンテンツページのウィジェットにあった2つの設定メニューは、1つのメニューに統合されました。
予期しないエラーが発生しました。
このセクションには、DXPの機能および性能の重大な変更点に関する情報が含まれています。重大な変更点または内部コードについては、こちらのリンクをご覧ください。
非推奨機能フラグのパターン定義に従って、機能フラグはインスタンス設定の下に移動されました。
コレクションページはページ管理者から削除されました。 アップグレードパスは、機能的な変更なしに、コレクションページをコレクション表示のあるコンテンツページに置き換えます。
解決策は、ルートモデルの仮定における "制限 "のために、データモデルに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 プロパティが変更されました。他のすべてのモデルでプロパティがどのように機能するかに合わせるためのロジック:
現在はVIEWアクションにのみ適用されます。
現在は制限されています: あるページにVIEWアクセスするためには、ユーザーはその特定のページとそのすべての祖先ページのVIEW権限を持っていなければなりません。
Ehcache 2.xは、Javaコミュニティによって公式にメンテナンスされなくなりました。DXPの内部キャッシュをEhcache 3.10.8に移行しました。
つまり、既存のehcache設定 xml ファイルは直接互換性がなく、新しい3.x環境でエラーや予期せぬ動作を引き起こす可能性が高いということです。 ユーザーはこれらの設定を見直し、新しい3.xスキーマに従って書き換える必要があります。