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.
Release Notes
このセクションには、DXPの機能および性能の重大な変更点に関する情報が含まれています。重大な変更点または内部コードについては、こちらのリンクをご覧ください。
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.
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は引き続き完全にサポートされます。
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
2024.Q2 リリース以降、Portalのランタイムには Java 17 または 21 がすでに必要ですが、ソースコードはJava 8でもコンパイルできました。2025.Q1 リリースでは、コンパイルに Java 17 または 21 も必要になります。
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 Display tab in the Review Changes screen now renders Display Page Templates and content that uses those templates (e.g., Web Content Articles, Blog Entries). Previously, these were not previewable — the Display tab was either empty or disabled for such content.
Why was this change made?
This change allows content reviewers to see the real end-user layout before publication. It significantly improves quality assurance by reducing publishing errors and increases confidence that the final layout will match expectations — especially for structured content and enterprise use cases (e.g., FHLBNY). This change improves usability and eliminates a gap in the review process that could result in visual inconsistencies post-publication.
How should I update my features or implementation?
No changes are needed.
What changed?
The Data tab in the Review Changes screen for Web Content Articles now displays all editable fields, including those created via custom structures. It also shows field labels and values exactly as defined by content creators.
Why was this change made?
Previously, only a subset of fields was shown, which often led to missed content changes during the review process. This update makes it easier to catch all modifications, especially in highly customized structures — enhancing accuracy and trust in the publishing process.
How should I update my features or implementation?
No changes are needed.
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 change was already done for text editable, since the button fragment have to allow text only, and it was forgotten for the link editable.
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.
At the LPD-46627: Enhancing SAML to be able to Sync User GroupsClosed story we modified the SAML userGroups membership management according to the portal’s standard way. With that we introduced a namespace for the attribute which seems causing inconveniences to customers, described in the LPD-66611: userGroups Attribute Name Changed to membership:userGroups, Breaking Liferay IdP IntegrationsClosed bug ticket.
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.