Liferay’s Countries feature was migrated from being a Commerce feature to a DXP feature, thus Commerce’s Countries page was removed. Users that manage Countries will now be able to manage them through the Countries Management page under the Control Panel.
Release Notes
このセクションには、DXPの機能および性能の重大な変更点に関する情報が含まれています。重大な変更点または内部コードについては、こちらのリンクをご覧ください。
To bolster permissions management and elevate user awareness concerning content, users will now be prompted to confirm permissions during the initial publishing or saving process, requiring an additional click. Subsequent saving or publishing actions will not require this confirmation.
何が変わったのか？
以前は、一部の修正コンフリクトとすべての修正削除コンフリクトは手動で解決する必要がありました。このようなケースは、「変更のチェック」画面に表示され、解決するために手動でのユーザー操作が必要となる。 これらの変更は、パブリケーションで行われた変更でプロダクションを上書きすることで自動的に解決され、[変更の確認]画面には表示されなくなりました。
この変更はなぜ行われたのか？
以前の動作では、ユーザーは多くの種類のコンフリクトに手作業で対処する必要があり、通常、時間のかかる作業でした。この新しい動作は、パブリケーションのユーザーが必要な修正を出版できることを保証しながら、パブリケーションプロセスにおける摩擦を軽減します。
誰が影響を受けますか？
すべてのパブリケーション・ユーザーが影響を受けますが、コンフリクトの解決とコンテンツのパブリッシングを担当するユーザーに焦点が当てられています。
重大な変更をより適切に適用するには、機能または実装をどのように更新する必要がありますか?
パブリケーションのユーザーは、本番の変更を上書きする権限をより強く持つようになりました。エンドユーザーのシナリオで、修正削除のケースで人間による検証がまだ必要であることを理解している場合、インスタンス設定 > パブリケーションで修正削除の競合トグルを使用することで、以前の動作を復元できます。
Content is no longer classified as translated solely upon the translation of its title. Now, when a user translates any field, not just the title, but also the content status changes to "Translating". It will only be considered translated when all fields have been translated.
The "Recent" filter now displays the creation date information instead of the modified date.
The "Mine" filter now displays the creation date information instead of the modified date.
The name of the reserved variable ID has always referred to the article ID so it has been changed to: Article ID. A new ID variable has been added that refers to the ID.
Tag values are now case-sensitive.
何が変わったのか？
新しい一括操作機能により、パブリケーション内の複数の変更を選択して管理できます。 ユーザーは、管理バーから一括して変更を移動または破棄できるようになった。 これにより、大規模なパブリケーションの管理が簡素化される。
なぜこのような変更がなされたのか？
以前は、ユーザーはそれぞれの変更を個別に管理しなければならず、時間がかかっていた。 この変更により、ユーザーの効率が向上し、管理負担が軽減され、大規模なパブリケーションに対してよりスケーラブルなプラットフォームとなった。
新しい行動はユーザーにとって良いことなのか？
時間と労力を大幅に節約し、複数の変更を迅速に管理することが容易になる。 この結果、大量の変更を処理する際に、よりスムーズで迅速なユーザーエクスペリエンスが実現します。
誰が影響を受けるのか？
大規模なパブリケーションを管理したり、複数の変更を処理する必要があるユーザーは、このアップデートの恩恵を受けるだろう。 頻繁に変更箇所を移動したり、破棄したりするユーザーのプロセスを効率化します。
どのように自分の機能や実装を更新すれば、より良いブレークチェンジを採用できるのか？
必要に応じて、この機能は、インスタンス設定 > 機能フラグ > feature.flag.LPS-171364=true または パブリケーションの一括アクション (LPD-20183) の機能フラグで有効/無効にできます。
何が変わったのか？
パブリケーションのサイズ分類がレビューの変更画面に表示されるようになり、パブリケーションのサイズに基づいてLight、Medium、Largeに分類されるようになりました。 ユーザーが分類の上にカーソルを置くと、ポップオーバーで説明が表示され、パブリケーションサイズがパブリケーションのプロセスに与える潜在的な影響について知ることができます。
なぜこのような変更がなされたのか？
この変更により、ユーザーはパブリケーションの規模を把握しやすくなり、パブリケーションのプロセスをより適切に計画できるようになります。 これは、大きなパブリケーションにより多くの時間を割り当てるようユーザーに促すことで、パフォーマンスの問題を防ぎ、競合を減らすことを目的としています。
新しい行動はユーザーにとって良いことなのか？
この新しい分類は、パブリケーションの複雑さをより明確に把握し、ユーザーが予期せぬ遅延を避けるのに役立つ。 また、ワークフローを積極的に管理することで、よりスムーズな公開プロセスを実現することができます。
誰が影響を受けるのか？
すべてのパブリケーションユーザーが影響を受けますが、複数の変更に対応するユーザーや、Webサイトを公開する際に達成しなければならない締め切りがあるユーザーにより重点を置いています。
どのように自分の機能や実装を更新すれば、より良い重大な変更点を採用できるのか？
必要に応じて、この機能を完全に動作させるには、インスタンス設定 > 機能フラグ > パブリケーションツールバーの追加コンテキスト (LPD-20556) の機能フラグが必要です。
何が変わったのか？
レビュー変更画面にプログレスバーが追加され、公開プロセス中にリアルタイムで視覚的なフィードバックが得られるようになりました。 ユーザーは、公開が開始されるのを待っている間、プログレスバーが表示され、公開プロセスの残り時間を知ることができます。
なぜこのような変更がなされたのか？
以前は、公開プロセスにかかる時間をユーザーが視覚的に示すことはできませんでした。 この変更は、透明性を提供することによって、ユーザーエクスペリエンスを向上させ、ユーザーの期待をよりよく管理できるようになります。
新しい行動はユーザーにとって良いことなのか？
新しいプログレスバーは、明確でリアルタイムのフィードバックを提供することで、ユーザーの満足度を高めます。 これにより、ユーザーはパブリケーションスのケジュールを把握しやすくなり、プロセス中の不安を軽減できます。
誰が影響を受けるのか？
すべてのパブリケーション利用者が影響を受けますが、これまで待ち時間が不明瞭であった大規模なパブリケーションや複雑なパブリケーションを扱う利用者に焦点が当てられています。
どのように自分の機能や実装を更新すれば、より良い重大な変更点を採用できるのか？
現在のプロセスに変更は必要ありません。
ユーザーがAnalytics Cloudで削除されると、永久に削除される前にまず抑制されます。 その結果、ユーザーごとに2つのリクエスト（抑制と削除）が表示されます。
以前は、各ユーザーの削除には2つの別々のリクエストが発生していました。 現在では、すべてのユーザーが1つの抑制および削除リクエストにグループ化され、リクエスト数が減少しています。 たとえば、各リクエストには、ユーザーごとに個別のリクエストを生成する代わりに、影響を受けるすべてのメールアドレスのリストが含まれるようになりました。
Analytics Cloud > Settings > Data Control & Privacy > Request Logで削除ログを確認できます。
フラグメントは、コレクションディスプレイの最初のアイテムにのみドロップしてマッピングできます。
Webコンテンツの編集時に、「下書きとして保存」と「キャンセル」オプションが表示されなくなりました。その代わりに内容は自動的に下書きとして保存されます。
自動保存の実装により、ユーザーはコンテンツの編集中に進行状況が失われる心配がなくなりました。自動保存により、すべての変更がバックグラウンドで継続的に保存されるため、予期せぬ中断によるデータ損失のリスクが軽減され、安心感が得られます。
This change was made in order to prevent fragment changes propagation when a user changes the cacheable option and then saves it. This was creating performance issues for some customers.
This change will benefit customers in terms of performance, as unnecessary propagations will no longer occur when the cacheable option is changed.
No changes are expected for customers' implementations. Just the awareness that this option is now somewhere else.
The filtering options for "With approved versions," "With scheduled versions," and "With expired versions” are now designated as "Approved," "Scheduled," and "Expired," respectively. Rather than filtering all web content with a given status, it now distinctly displays content or versions in the specified status.
The self bootstraping style *SearchRegistrar has been changed to service collecting of ModelSearchConfigurator.
Indexer registration code for custom entities has to be adjusted to become an OSGi service of type ModelSearchConfiguratorand to move all previous ModelSearchConfigurator setter call parameter as corresponding ModelSearchConfigurator getter return value.
We changed the default configuration such that if a Menu Display widget is placed on a Page Template, the default configuration for it will be "Pages Hierarchy" (unless there are no Pages at all on the Site). It will display as "Pages Hierarchy" even if Private Pages are enabled. If Private Pages are enabled, an alert will appear on the Page Template letting the user know that the Menu Display may appear different if the inherited page has the opposite privateLayout value to the menu currently being rendered.
When a Page inherits this Page Template, the alert message does not display on the Page, and the Navigation Menu will be configured for either Public Pages Hierarchy or Private Pages Hierarchy depending on whether the page is public.
（ページの）レイアウトの permissions.view.dynamic.inheritance プロパティが変更されました。他のすべてのモデルでプロパティがどのように機能するかに合わせるためのロジック:
現在はVIEWアクションにのみ適用されます。
現在は制限されています: あるページにVIEWアクセスするためには、ユーザーはその特定のページとそのすべての祖先ページのVIEW権限を持っていなければなりません。
Ehcache 2.xは、Javaコミュニティによって公式にメンテナンスされなくなりました。DXPの内部キャッシュをEhcache 3.10.8に移行しました。
つまり、既存のehcache設定 xml ファイルは直接互換性がなく、新しい3.x環境でエラーや予期せぬ動作を引き起こす可能性が高いということです。 ユーザーはこれらの設定を見直し、新しい3.xスキーマに従って書き換える必要があります。