With this new feature, Instance Administrator can export audit data filtered by user as well as filtered by site. They can also store site data for audit events.

We display some additional messages to Site and Site template Administrators when there is a Friendly URL collision between Site page and Site template page.

From now on, users can view the summary of failed staging processes, which can help them to solve the issue(s) which caused the staging process to fail.

Using LAR files for export/import in the portal are stored in DM. These LAR files can increase the size of the DM significantly. We have changed this, so the LARs are not kept in the DM after the export/import process.

On LPS-136108: URLs using a virtual host are always reformatted on export and import, even in cases where they don't need to be the validation of the Web Content was added for Liferay layout URLs. Before this, there was no validation, so users could create their customizations where they could add different URLs to the Web Content's content. After the validation was added, some custom URLs became unable to be added to the Web Content. From user perspective this was a feature loss, so we decided to deliver a feature to make customers able to add their custom URLs to Web Content's content field. This feature is about adding a configuration for storing the user’s relative URL patterns. So custom URLs containing this pattern would bypass validation.

Before the Import process starts, users are now asked via a confirmation dialog if the user is sure about deleting application data . Also, we have improved the error message for Staging related references.

As a Site Template Administrator: template propagations are run completely in the background and background tasks are executed in a sequence. The LAR from the Site Template export is cached, so different Sites can reuse it.

• LayoutSetPrototypeMergeBackgroundTaskExecutor always uses the latest Template version for the propagation.
• If there is already a queued background task for the Site, we don’t create a new one.
• If there is a background task in progress, we only create a new background task if the Template was modified.

Two new configuration options were added:

• The first one gives the users the chance to automate an existing feature, which improves performance.
• The other one is about displaying the Advanced Staging configuration screen to the users, improving usability.

This is the Staging related implementation of a bigger change. On the Staging side, the LXC Client extensions (Remote apps) could be handled. To make this feature completely working, LPS-182183: Export/Import of FrontEnd Client Extensions is also needed.

• Deletion of property upgrade.log.context.name. Now all upgrade related log lines are automatically tagged with the key upgrade.component, which provides more meaningful information.
• Upgrade Report is now compatible also with upgrade on startup, and it can be printed as Log Thread Context information.
• Upgrades log the result and the type of upgrade that has taken place after all the upgrade processes finish.
• New mBean available with upgrade on startup to obtain real time information about the status and the result of the upgrade.

Creation of a new property called upgrade.report.dl.storage.size.timeout that specifies the number of seconds that the upgrade report generation will wait for calculating the DL size before timing out. This property is set to 10 by default but it can be modified in the portal-ext.properties file.

Adds support for creating custom client extension development profiles in the same project.
For example, when the user creates a file called client-extension.dev.yaml , a new task will be available to the user called deployDev.

In order to allow developers to exclude directories from the build, a new property has been added: liferay.workspace.dir.excludes.globs= 

Kaleo Forms was already in maintenance mode. It is now being moved to deprecated, so it can be removed at the same time as DDL in about a year. This solution is being replaced by Objects, Workflow, and Form Container Fragments.

The portlets that are in the Contacts module will be deprecated.

These are:

1. Contacts Center
2. Members
3. My Contacts
4. Profile

In the first step, the modules were pushed to the maintenance mode.

These modules are obsolete ones and are no longer being used. They have been moved to deprecate and later it will be removed.

特定の行動に基づいて、より詳細な顧客セグメントを作成できるようになりました。 セグメンテーション機能を拡張し、標準的なウェブサイト活動だけでなく、カスタムイベントを含むオーディエンスのセグメンテーションが可能になりました。 ターゲットを絞った顧客グループを作成し、よりパーソナライズされた体験を提供することができます。 さらに、Liferay DXPは、カスタムイベント基準が変更されたときにアラートを提供し、セグメントの正確性と関連性を保証します。 顧客分析をより詳細に管理し、より適切なコンテンツを配信できるようになります。

オブジェクトに基づいた新しいOut-of-the-Box（OOTB）メールの通知テンプレート。 このテンプレートは、注文ステータスが「保留」に変更されると、注文作成者に自動的に送信されます。

この通知には以下の内容が含まれています:

• 注文番号

• 注文日

• アカウント名

• 配送先住所

• 注文商品の概要

• 注文合計

私たちはコマース通知を廃止し、新しい通知にはオブジェクトを使用します。

この機能では、製品仕様のカスタム選択リストを作成および管理する機能が導入されています。ユーザーは製品属性の特定の値を定義できるようになり、データの一貫性と効率が向上します。この機能には、新しい候補リストを作成したり、既存の候補リストを仕様ページに直接追加したりするオプションが含まれています。

ロールマネージャーは、ロールのUI内でオブジェクトエントリの権限を直接定義できるようになりました。新しい「オブジェクト」メインメニュー項目が 権限の定義タブに追加され、すべてのカスタム オブジェクトがリストされ、より詳細な権限の割り当てが可能になりました。

注文の詳細に基づいて正確なUPSの送料を顧客に提供することにより、チェックアウトのエクスペリエンスを向上させます。 マーケットプレイスで購入可能なクライアント拡張機能を使って、この機能をオンラインストアに簡単に統合できます。

Adyenペイメントコネクターでオンラインストアを強化

Liferay DXPは現在、世界有数の決済プラットフォームであるAdyenとのシームレスな統合を提供しています。 この強力な組み合わせにより、企業は幅広い支払い方法を受け入れ、不正行為を減らし、チェックアウトプロセスを最適化することができる。 決済管理を簡素化することで、Liferay DXP with Adyenはビジネスの成長に集中できるようにします。

この機能強化により、新しく作成されたページに対して設定可能なデフォルトの権限が導入されました。管理者は、インスタンスレベルとサイトレベルの両方でこれらの権限を設定できます。インスタンスレベルの設定は新しい インスタンス設定]パネルで管理され、サイト固有の上書きはサイト設定の領域で設定できます。

この取り組みの主な変更点は、Cookie マネージャーを通じて Analytics Cloud (AC) 追跡を制御する新しい機能です。明示的 Cookie 同意モードの説明を更新し、設定処理を介してこの構成を有効にすると、Analytics Cloud の追跡やその他の機能が無効になることを明確にしました。ここで、明示的 Cookie 同意モードが有効になっている場合、ユーザーがその使用に同意するまで Cookie は設定されません。それ以外の場合、ユーザーがオプトアウトするまですべての Cookie が設定されます。

また、Cookie リストという名前の新しいユーティリティ ページも導入しました。これは、Liferay でサポートされているすべての Cookie の中心ハブとして機能します。このページには、Cookie の 4 つのカテゴリ (必須、機能、パフォーマンス、パーソナライゼーション) がすべてリストされており、目的や有効期限など、特定の Cookie ごとの詳細情報が提供されます。そのために、Cookie の管理を容易にする新しいシステムオブジェクトを作成しました。顧客が追加のサードパーティCookieを使用する場合、これらのCookieの新しいエントリを簡単に追加でき、ユーティリティページに自動的に表示されます。

さらに、ユーザーが抑制されると、そのデータは完全に匿名化されるため、特定の個人に遡ってデータを追跡することは不可能になります。

このイニシアチブでは、ダウンロードレポートとパス分析ツールのユーザー・インターフェイス（UI）を強化し、両ツールに一貫性のあるデザインパターンを確立することに重点を置きました。 特に、PDFやCSVなど様々な形式を含むダウンロードレポートの表示を、ダウンロードレポート機能の中で標準化することを約束しました。 この戦略的投資は、ステークホルダーの進化するニーズに効果的に対応する高品質なソリューションを提供するという当社の献身を強調するものである。

ユーザーは、コンテンツダッシュボードの新しいフィルター機能を使用して、特定のサイズのカテゴリ (小、中、または大) ごとに画像やビデオを効率的に見つけることができるようになりました。さらに、作成、表示、有効期限、変更、公開、レビューなどのさまざまなライフサイクルイベントの日付の範囲に基づいてコンテンツやドキュメントを簡単にフィルタリングできます。この機能強化により、コンテンツ管理が合理化され、関連ドキュメントへのユーザーのアクセシビリティが向上します。

ユーザーは、ゲストユーザーに表示されていないドキュメント&メディアを、リスト、カード、テーブルビュー、またはドキュメントエディター内でアイコンを通じて簡単に見つけることができます。さらに、この機能はアイテムセレクターからアクセスできるため、ゲストユーザーが表示できないドキュメントをユーザーが識別できるようになります。

パブリケーションは、ユーザーが変更をレビューするための最終エンドポイントを提供するため、ワークフローの変更もレビューできれば、コンテンツ編集者にとっては非常に有益です。

大規模なパブリケーションでは、許容できないパフォーマンスの低下が観察されます。パブリケーションには多数の個別の変更が含まれているため、現在のシステムは、特に競合チェックおよびパブリケーションのパブリッシング中に、許容可能なパフォーマンスレベルを維持するのに苦労しています。これら 2 つのフェーズでは、手書きの SQL クエリを活用してタスクを実行し、パブリケーションが永続化レイヤーを介してショートカットできるようにして、小規模なパブリケーションのパフォーマンスを最大化します。ただし、大規模なパブリケーションでは、一貫したパフォーマンスを確保するためにさらに考慮する必要があります。

アップグレードプロセスによって ctColectionId 列を考慮しない場合があり、特に古いバージョンのパブリケーションを使用しているお客様に不整合が発生する可能性があります。

標準の rest-config.yaml にchangeTrackingEnabledを追加して、サービスがパブリケーションのサポートを指定しなければならないようにしました。これにより、将来のヘッドレスAPIで変更追跡を可能にするプロセスが簡素化されます。

オブジェクト間の1対1の関係によりワークフローを合理化する新機能を導入しました。ユーザーは、プライマリオブジェクトのCRUDビューから直接ネストされたオブジェクトを作成および更新できるようになり、データ セットマネージャー (DSM) から変換されたシームレスな削除および表示操作を利用できるようになりました。このアップデートにより、データ管理がよりスムーズかつ効率的になりました。

ユーザーが、フラグメントおよびコレクション表示ですでに定義済みのWebコンテンツのストラクチャの反復可能なフィールドをマッピングできるようになりました。

/search と /suggestions のAPIには、次の機能強化が加えられています:

• /searchのサイト (グループ) ID と外部参照コード (ERC) をサポートする新しいオプションの scope パラメーターが追加されました。/suggestionsのscopeパラメーターも、同じセマンティクスを持つように更新されました。

• /search は現在 RELEASE ステータスです。

• APIは現在、/o/search/v1.0/ エンドポイント下で利用可能で、サーバー側の転送を介した呼び出しによる現行の /o/portal-search-rest/v1.0 呼び出しの後方互換性があります。

詳細はドキュメントをご参照ください。

Elasticsearch 8.15.x がテストされ、対応するLiferayのバージョンとの互換性マトリックスに追加されました。

注意: Elasticsearchの新しいマイナーバージョンとの互換性は、2つの方法でテストされています:

1. 最新-最新: 最新の利用可能な Elasticsearchのマイナーバージョンを使用して、最新のLiferayバージョンをテスト → 例: Master/2024.Q3 + Elasticsearch 8.15

2. ミニマム-最新: Elasticsearch 8の互換性が最初に利用可能になったミニマムのLiferayバージョンを、Elasticsearchの最新のマイナーバージョンでテスト → DXP 7.4 U81/DXP 7.3 U31 + Elasticsearch 8.15

このようにすることで、Liferayはより広範なデプロイメントのベースが最新の検索エンジンバージョンでスタックを運用できるようになります。

Elasticsearchは通常、およそ 2 か月ごとに新しいマイナー バージョンをリリースするため、これは定期的なプロセスであり、四半期ごとに計画されたアクティビティです。

Elastic’s product lifecycle に従い、Elasticsearch 7.17.xバージョンはElasticsearchバージョン9がリリースされるまでサポートおよび保守されます。 Elasticsearch 9.0.0は、2025年初頭にリリースされる予定です。

したがって、Liferayでは、7.17.x をデプロイメントしているすべてのお客様に対し、互換性のある最新の Elasticsearch 8.x バージョンへのアップグレードプロジェクトの計画段階を開始することを強くお勧めします。

Elasticsearch 8との互換性は7.4 U81+で利用可能です。→ Operating Liferay 7.4 GA/Update 81+ with Elasticsearch 8 - Liferay

注意: Elasticsearch 8.x との互換性は、バンドルされている Elasticsearch 7 コネクタと Elasticsearch 8 の REST API Compatibility によって提供されます。

Liferayには、クライアントバージョンとして7.17.21を使用し、また開発・テスト用にSidecar ElasticsearchサーバーのバージョンとしてアップデートされたElasticsearchコネクターが同梱されています。

条件コントリビューターの設定は、より小さなフットプリントでブループリントのJSON 内に保存されるようになり、デフォルトの設定（すべてのコントリビューターを有効化 → Enable All）または新しい Disable All オプションを使用する場合、ブループリントのサイズが 90% 以上削減されます。

異なるオプションの動作は以下のとおりです:

• Enable All を使用すると、現在および将来プラットフォームに導入されるすべてのクエリの条件コントリビューターが自動的に有効になります。Disable All は逆の動作をします。

• カスタマイズ では、設定は指定されコントリビューターのリストにロックされます。