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.

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.

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.

The "Mine" filter now displays the creation date information instead of the modified date.

The "Recent" filter now displays the creation date information instead of the modified date.

A new SEO menu has been added in Instance Settings with an item selector to include specific Sites or all of them, in the sitemap of the Company through the Company's Virtual Host, and the default site cannot be deleted from the list. If the default site has a Virtual Host defined, it will not be added to the company's XML sitemap although listed in the configuration.

Users are currently presented with a group of features that are not relevant in the configuration page for Utility Pages. These non-applicable features have been removed while preserving the essential HTML Title, HTML Description, and SEO configuration elements.

After searching with a keyword and selecting facets, searching with a new keyword (in either using the header Search Bar or any Search Bar widget instance on a page) will clear all active facet selections.

The old behavior can be enabled via the Search Options widget by ticking Retain Facet Selections Across Searches option.

This affects any custom code using Liferay’s API methods User.getRemotePreference(String) and User.getRemotePreferences().

The API supporting logic has to collect and hold cookies in User object, causing unnecessary CPU and memory overhead. These methods were just a convenient shortcut to get the user's current request's cookies with REMOTE_PREFERENCE_ name prefix. The same logic can be done by directly getting necessary cookies from request.

• What changed? Currently, the translatable object fields use the configured languageId from the user. With this change, it is going to use the preferred Locale given by the DTOConverterContext instead.
• Why was this change made? This change is needed in order to return the appropriate translatable object field values for the language setting in the Accept-Language header.
• Who is affected? Every user that calls the translatable object fields.
• How should I update my features or implementation to better adopt the breaking change? Adding or removing (depends on the cases) the Accept-Language header.

Tag values are now case-sensitive.

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.

Sites are not browsable for non-admin users in Breadcrumb portlet when the site has Membership restricted or private.
The Default Layout permission was replaced with the current Group check.
Disable Group membership checking since it has no relationship to layout browsability.

When we create a new Site the Allow Manual Membership Management option will be disabled by default to avoid uploading malicious files to the Documents and Media portlet.

All filtering in web content now only applies to the current folder. Previously, certain filters exhibited behavior limited to the current folder and now it has been standardized to all filters.

Searching after filtering will clear all existing filters and give a search from the entire data set.

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.

From now on, the segments tab for the Administrator role will no longer be displayed in the assignees' tab. Assigning the Administrator role through segments is not allowed.

The configuration sections in Utility Pages are not enabled, as the other pages, due to their use being more restricted. The implementation of these settings should occur by analyzing each case.

As mentioned in the new features section the following properties having been transformed in configurations, so they are no longer available in the properties files:

• session.timeout.auto.extend
• session.timeout.auto.extend.offset

Previously our AB Testing feature supported multivariate testing. With the addition of multiple variants, the time to completion and the calculations required would increase exponentially. This caused many issues for our customers. As such we have decided to pare back this functionality to provide a higher quality experience for our users. Now our AB Testing feature only supports 1 variant, in addition to the control. This makes our feature truly an AB Test rather than a Multivariate Test. There is the possibility of re-enabling multivariate testing in the future, but that will depend on the needs from our customers.

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.

Current options in System Settings > Documents and Media > Cache Control are:

• Public
• Private

And Private is the default option.

From now on, we are adding a new option No Cache that will allow configure this option to “private, no-cache, no-store, must-revalidate" and it will be used as default value, so it changes current default behavior:

With the upgrade of the client libraries, the minimum compatible Elasticsearch minor version shits to 7.17.x.

When the server is lower than the expected version, the DXP won't start-up, but fail with an error in the DXP console:

10-22 10:45:22.619 ERROR [main][ElasticsearchSearchEngine:375] Elasticsearch node es-node-1 does not meet the minimum version requirement of 7.17

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.

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.

これらのアプリケーションサーバーはベンダーからのアップデートを受けれなくなったため、2024.Q3 以降からサポートが削除されます。

Wildfly 26.1 および Jboss EAP 7.4は引き続き完全にサポートされます。

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として利用可能になりました。 日付ファセット・ウィジェットは使用できなくなりました。

詳細については、検索のカスタムファセットの日付範囲と範囲集約をご参照ください。

Until now, when we had 2 ItemSelectorViews with the same name, only one of them was taken into account when rendering. This is more noticeable now with the CMS where we have object definitions like Blogs. In order to allow the users to select all the object definitions and legacy entities, now they appear duplicated when they have the same name.

We recently updated our tracking logic within documents, replacing the previewed event with a new event: impressionMade. To align with this change, we also updated our current API to include a new metric — impressionMadeMetric — which consolidates impressions by summing both the new impressionMade events and the legacy previewed events.

What Changed?

The Configuration Headless API now exposes and manages site-scoped configurations that were previously unavailable through export/import operations. During import, existing configurations for a site are now overridden with the incoming configuration data based on groupId scope matching.

Why Was This Change Made?

This change ensures that site migrations are more complete and consistent, including configuration data that was previously missing.

How should I update my features or implementation?

• No changes are needed.

The results of a search haven’t to be shown the content of a fragment is within a collection display and is not indexed.

The system-wide Mail Settings for DXP were migrated to use the standard system configuration framework.

The system options in Server Administration > Mail were moved to System Settings > Email > Virtual Instance Scope > Mail Settings

The existing settings from previous releases will be automatically migrated during the database upgrade process.

The following portal properties were removed since they are now defined by configuration properties:
LIST OF PROPERTIES

Following standard configuration patterns, Instance Settings > Email > Mail Settings will have default values inherited from the System Settings. The administrator for Portal Instances can now view the default values, override, or reset to default.

Please refer to Configuring Mail - Liferay Official Documentation for additional details.

The Object Inheritance feature has been updated to support more flexible scenarios, which introduces changes to the previous behavior:

• Child definitions can now be associated with multiple parent definitions.
  Previously, a child could only inherit from a single parent.

• Child entries can now exist without a parent (standalone entries).
  Before this change, every child entry was required to belong to a parent.

• The relationship field is no longer mandatory at the object-definition level.
  Previously, the relationship field was always required when inheritance was enabled.
  Now, it becomes mandatory only when the entry is created in the context of a parent.

• Permission and configuration inheritance now depends on whether the child entry has a parent.
  Standalone entries no longer inherit permissions or configuration from a root object.

When users have an object entry related to another system object entry, users now need the VIEW resource permission of the related entry in order to add the object entry.

This change was made to enforce data integrity standards across DXP covering potential security breaches our users could encounter. This will affect all object admins modeling object definitions related to the following asset types

• Accounts

• Organizations

• Picklists

• Postal Addresses

• Roles

When object entries are related to an asset in the aforementioned list, users must now have the VIEW resource permission on the related asset in order to ADD the object entry. This also applies to users who are trying to import an object entry with a related asset from the list.

What changed: Leftover utility classes previously duplicated between portal-kernel and the Petra libraries (petra-string, petra-reflect, etc.) have been removed from portal-kernel.

Why: The duplicated classes were not adding value; removing them simplifies the codebase.

Who is affected: Developers importing these utilities directly from the old portal-kernel packages.

How to adopt: Update imports to the equivalent Petra package. This is a package name change only — no behavioral changes are required.

What changed: All findByXxx_PrevAndNext and filterFindByXxx_PrevAndNext methods have been completely removed from generated persistence classes (*Persistence, *PersistenceImpl, and *Util) for entities utilizing Service Builder 7.4+. Previously, these methods returned a 3-element array containing the previous, current, and next neighboring entities from an ordered result set.

Why: To significantly reduce codebase bloat. Within DXP, these methods generated over 600,000 lines of code but were only used in three internal places. Existing finder methods easily replicate this behavior.

Who is affected: Developers using Service Builder on 7.4 or Quarterly releases who currently rely on PrevAndNext finder methods in their custom logic.

How to migrate:

Choose one of two methods based on your dataset size:

• List Lookup (Recommended): Fetch the current entity using findByPrimaryKey, then retrieve the full matching list using standard findByXxx methods. Find the current entity's index to grab the previous (index - 1) and next (index + 1) items.

• DSL Queries (For large datasets): Use dslQuery with a limit of 1 to execute two targeted database queries — one fetching the immediate previous entry, and one fetching the immediate next entry.

As part of a major search and re-indexing performance optimization, several public search and indexing APIs have been simplified.

• Custom indexer implementations extending BaseIndexer must rename their doReindex(String[] ids) override to doReindexCompany(long companyId).

• Modules using ModelIndexerWriterContributor will need minor updates as helper classes (BatchIndexingActionable, ModelIndexerWriterDocumentHelper) have been removed in favor of direct use of their underlying equivalents.

• The Queries OSGi service has been replaced by the static QueriesUtil, and a small number of other search API methods have had parameters removed or their types updated to reflect their actual usage

Please see full breaking changes list for details.

File system artifacts are now deleted when a company partition is removed.

Previously, removing a Virtual Instance (company) with Database Partitioning enabled only dropped the database schema, leaving behind file system artifacts such as Document Library files (data/document_library/{companyId}), search indexes, and configuration files.

Action required: If Database Partitioning is enabled, ensure any needed data is backed up before deleting a partition, as file system artifacts will no longer be recoverable after deletion.

タグフィルターウィジェットはタグをアルファベット順にソートしていましたが、お客様はより多くの用途のタグを最初に見ることを期待しているようです。私たちはこの変更が理にかなっていると考え、このウィジェットの動作を修正しました。

何が変わったのか？

以前は、一部の修正コンフリクトとすべての修正削除コンフリクトは手動で解決する必要がありました。このようなケースは、「変更のチェック」画面に表示され、解決するために手動でのユーザー操作が必要となる。 これらの変更は、パブリケーションで行われた変更でプロダクションを上書きすることで自動的に解決され、[変更の確認]画面には表示されなくなりました。

この変更はなぜ行われたのか？

以前の動作では、ユーザーは多くの種類のコンフリクトに手作業で対処する必要があり、通常、時間のかかる作業でした。この新しい動作は、パブリケーションのユーザーが必要な修正を出版できることを保証しながら、パブリケーションプロセスにおける摩擦を軽減します。

誰が影響を受けますか？
すべてのパブリケーション・ユーザーが影響を受けますが、コンフリクトの解決とコンテンツのパブリッシングを担当するユーザーに焦点が当てられています。

重大な変更をより適切に適用するには、機能または実装をどのように更新する必要がありますか?

パブリケーションのユーザーは、本番の変更を上書きする権限をより強く持つようになりました。エンドユーザーのシナリオで、修正削除のケースで人間による検証がまだ必要であることを理解している場合、インスタンス設定 > パブリケーションで修正削除の競合トグルを使用することで、以前の動作を復元できます。

何が変わったのか？
パブリケーションに「古い」というラベルを付けてユーザーがコンテンツを公開できないようにする古い機能は、デフォルトでオフになりました。

この変更はなぜ行われたのか？
ユーザーは、Liferayのアップグレード前に作成されたパブリケーションを公開できるようにしたいと考えていましたが、競合管理の改善により、これが可能かつ安全になりました。

誰が影響を受けますか？
進行中のパブリケーションを持ちながら、Liferay をアップグレードした、またはアップグレードを計画しているユーザー。

破壊的な変更をより適切に適用するには、機能または実装をどのように更新すればよいですか？
必要に応じて、インスタンス設定 > スキーマバージョンチェックの有効化の切り替えによって、この機能を有効/無効にできます。デフォルトではオフになっています。

コンテンツページのウィジェットにあった2つの設定メニューは、1つのメニューに統合されました。

非推奨機能フラグのパターン定義に従って、機能フラグはインスタンス設定の下に移動されました。

コレクションページはページ管理者から削除されました。 アップグレードパスは、機能的な変更なしに、コレクションページをコレクション表示のあるコンテンツページに置き換えます。