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

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

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.

Currently, when a user make a call to Batch in order to import any entity, the error returned has a different structure than a regular call to the Rest API. Specifically, the structure that is different is the one related to "failedItems" information.

With this change, users will have the same structured information no matter the endpoint they are using so matching errors and show it in the UI will be more simple.

The main change is:

Current structure:

"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" } 
  ]

New structure:

"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\"}]"
  } 
  ]

Tag values are now case-sensitive.

What Changed?

Previously, some Modification Conflicts and all Modification Deletion conflicts required manual resolution. These cases would show up in the Checking Changes screen, requiring manual user action to be resolved. They are now automatically resolved by overwriting production with the changes made in the publication and won't be displayed in the Checking Changes screen.

Why Was This Change Made?

The previous behavior required users to manually address many types of conflicts, which was usually a time-consuming effort. The new behavior reduces the friction in the publishing process while guaranteeing publications’ users they will be able to publish the needed modifications.

Who Is Affected?
All publication users are affected, but the focus is on the ones responsible for solving the conflicts and publishing the content.

How Should I Update My Features or Implementation to Better Adopt the Breaking Change?

Consider that now Publications’s users have more power to overwrite production changes. If you understand that the end-user scenario still requires human verification in Modification Deletion cases, the previous behavior can be restored by using the Modification Deletion Conflicts Toggle on Instance Settings > Publications.

Tag filter widget used to sort tags in alphabetical order but it seems customers expect to see the tags with more uses first. We think this change make sense so we have modified the behavior for this widget.

When performing a GET on text fields using the headless API and results in empty contents, the output returns ”” instead of being skipped. This change gives more flexibility to the users to decide what each user will do with the information.

Users should review all GET requests on text fields to adapt to this change.

Java 17 or 21 is already required for Portal runtime since 2024.Q2 release, but the source code was still able to be compiled on Java 8. With the 2025.Q1 release, Java 17 or 21 will also be required for compile.

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

• Solution introduces 2 breaking changes in the data model, because of a “limitation” in the root model assumptions

  • There were 2 relationships connecting Data Set and Data Set Action depending on the type of action. Now there is only one

  • type field in Data Set Action object definition has changed. Now it stores the type of action (item, creation, bulk). The old type now goes to target field

• As a result, previously saved data set actions will not be manageable by DSM, neither fragment will find them.