From now on most CSS files in Liferay have hashed file names at build time. For example, a clay.css file may appear at run-time with a randomly generated hash value in the name, like clay.(tvERyCVfuRc).css.

This hash value represents a unique version of this file, so the browser can identify that the file's contents haven't changed. This allows the file to remain in Liferay's cache indefinitely.

For those files that can not be hashed, because they are generated in runtime by the server depending on some parameter such as the css tokens, a new onfiguration is available in DXP to configure the TTL and the possibility to add the no-cache header, that ensures the revalidation of the asset with the server before to being served.

Also, hashed files have a fallback strategy based in TTL+eTag if they are called by their canonical name, this is a fallback for error in the import maps or old portlets that doesn’t know the name of a hashed file.

Key Benefits:

 

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

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

2. Elimination of Stale Resources: Hashed URLs prevents users from seeing outdated CSS 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, but updating their file name with a new hash when content changes.

 
 
 

When a user visits a page that contains a Data Set, there is a certain amount of data that can be altered in some ways:

• By filtering the data

• By ordering the data

• By changing the columns to show on the Table Visualization

• By changing the visualization mode

When users navigate away from the Data Set and then return, these unsaved changes are lost, leading to a frustrating user experience.

This feature automatically saves the current view state of a Data Set in the URL. This saved state will ensure the Data Set configuration is consistently recoverable when users navigate back (via browser history or links) and, crucially, that a shared URL provides colleagues with the exact same view.

Key Benefits:

 

• Avoid user frustration: When the user returns to the Data Set they face the same state they had when they left.

• Sharing what you see with other users: Users can share the link of a page with a Data Set and the user acessing that very page will face the same Data Set state.

 
 

Admins can now fully customize the Rich Text Editor configuration in CKEditor 5 using a new Client Extension. This new extension achieves feature parity with the old CKEditor 4 extension, allowing you to define which toolbars are available across different applications.

Bonus Feature: Unlike its predecessor, the CKEditor 5 extension supports dynamic loading of official CKEditor plugins not included by default in DXP, greatly expanding your customization options.

Key Benefits:

 

• Allow dev users to modify the CK Editor 5 configuration such as new block styles

• Allow the dev users to hide plugins such as the options in the editor toolbaar.

• Allow users to dynamically add more plugins from CK Editor official showcase.

 
 

The Liferay database upgrade process has been enhanced with automated database repair routines to improve the speed and reliability of DXP upgrades.

During the upgrade process, these routines automatically identify and correct common database inconsistencies or missing references.

These repair routines are targeted at known issues with data structures only, keeping your critical data content safe. Details of these repair processes are provided for review in the Liferay Upgrade Report after a database upgrade completes.

Key Benefits:

 

• Faster upgrades

• Minimize risks for current and future upgrades

• Automates data maintenance