From now on, most JavaScript files in Liferay DXP have hashed file names generated at build time. For example, a main.js file may appear at runtime with a randomly generated hash value in its name, such as main.(tvERyCVfuRc).js.

This hash value represents a unique version of the file, so the browser can identify that the file’s contents have not changed. This allows the file to remain in the browser cache indefinitely when the infinite caching strategy is selected.

In addition, the frontend caching infrastructure now supports both infinite caching and time/validation-based caching strategies. These strategies can be configured through Instance Settings.

For those JavaScript files that cannot be hashed because they are generated at runtime by the server depending on some parameters, a new configuration is available in DXP to define their TTL and the option to add the no-cache header. This ensures the revalidation of the asset with the server before being served.

Also, hashed files have a fallback strategy based on TTL + eTag if they are requested using their canonical name. This acts as a fallback for import map errors or legacy portlets that are not aware of hashed file names.

Key Benefits:

The new Liferay DXP caching strategy for JavaScript files improves performance and stability.

1. Faster Page Loads:
Significant reduction in subsequent load times.

2. Elimination of Stale Resources:
Hashed URLs prevent users from seeing outdated JavaScript after an update.

3. Reduced Origin Server Load:
Less server overhead, as browsers retrieve unchanged files directly from their local cache, saving CPU and bandwidth.

4. Cache busting:
Updated resources automatically force the browser to fetch the new version by changing the file name hash whenever the content changes.

"Promote Content among Environments" is a Liferay initiative that takes content promotion to the next level. By implementing a significant infrastructure change (based on Headless Batch APIs), processes are substantially streamlined, optimizing existing processes and adding new ones that enable more secure, stable, and efficient content promotion.

Now you can promote elements at the instance level, such as Object Definitions, Picklists, or Roles, and freely export and import Object Entries with any scope. With the new Lazy References infrastructure based on External Reference Codes, relationships are maintained and updated regardless of the order of importation.

Furthermore, the new Report List provides a comprehensive and detailed record of everything that happened during the import process. This new report is essential for new entities because import processes will run from start to finish without stopping with the first issue, reporting all errors so you can resolve them collectively instead of having to address them individually with each run. For non migrated entities, the behavior will be the current one finishing the process with the first error.

Key Benefits:

• Infrastructure improvement: based on Headless Batch APIs executions, the processes are more efficient, faster and more stable, allowing for easy optimization and showing a clear information about the status of each execution. Some of the old staging entities have been migrated to the new framework:

  • Pages (and related entities like templates, utility pages or master pages )

  • Vocabularies

  • Categories

  • Tags

• New capabilities at Instance level: The coverage of entities that can be promoted is expanded by adding a list of entities like:

  • Instance Level

    • Roles

    • Accounts

    • Account Groups

    • Organizations

• Full support for Objects: Now all related Objects entities are supported for export/import:

  • Object Definitions

  • Picklist

  • Object entries with Company Scope.

  • Object entries with Site Scope

• The order of execution no longer matters: Lazy references based on External Reference Code is the key. Now, for entities that are compatible with Batch, the related elements are not automatically exported. Thanks to the External Reference Code the references can be maintained even if the other element does not exist, making the order of importing irrelevant.

  If an element is missing, an empty shell might be created to maintain the correct structure, and if the information is included either manually or in a subsequent import, the element is updated, preserving all existing relationships.

  For the entities still using the old infrastructure, the relationships will be maintained using the old mechanism.

• All Import information in just one click: Thanks to Lazy References, the process will attempt to import all items for batch-migrated entities without stopping for errors or warnings. For non-migrated entities, the process will still stop at the first error. Due to this hybrid mode, batch-based entities will be imported first. All generated information will be available in a detailed list that can also be exported in CSV format for external processing if needed.