Dynamic Field Visibility in Custom Fragment Sites Low/No-Code
Field visibility can now be configured based on values within the same custom fragment. This enables fields to dynamically show or hide based on user input, supporting more responsive and context-aware interfaces.
This update gives teams more flexibility when building custom fragments, making it easier to support complex use cases without additional custom code.
Additional log after fragment Import Sites Low/No-Code
Customers very commonly deploy fragments through the deploy folder, we identified that we are missing one log once the fragment import finished. Until now Liferay added a message in the application server logs that show that the fragment import has started, but it never indicates when it finishes. Some advantages of logging when the import process finishes is that customers can check when the deployment is still in progress and when it ends, not only being informed in case of failures.
The existing documentation for Clay components and the API Table has been inconsistent in quality, often lacking detailed explanations and practical examples. This inconsistency makes it difficult for developers to effectively utilise these components, leading to confusion and an increased number of support requests.
Key Benefits:
Developers now have a better mechanism for generating API Tables for components, improving the overall understanding of component usage and available APIs. With detailed explanations and real-world examples.
With this new standardised documentation practices we can ensure a uniform quality and completeness across all components.
Clearer, more structured, and more practical documentation will reduce frustration and improve the development process.
Clearer documentation minimizes the need for external support, freeing up resources and improving response times.
Column Visibility & Sorting in FDS with Clay Table Integration Platform
We integrated the Clay Table's column visibility dropdown and column sorting functionalities into the Frontend Data Set. This makes a unified approach to table interactions across Liferay, replacing inconsistent custom implementations.
Key Benefits:
A more standard column visibility and sorting that guarantee a more usable and predictable interaction across the platform.
Reduces redundant code by aligning with the Clay Table’s native functionalities.
Developers no longer need to manage multiple implementations for similar features.
Ensures UI and UX consistency with Liferay’s design system.
Style Books in Liferay are now explicitly tied to a specific theme at the moment of creation, using the frontend token definition provided by that theme (via OSGi or themeCSS client extension). This structural link now ensures that each Style Book can only operate within the boundaries of its associated theme, eliminating cross-theme token contamination and enforcing clearer theme-based design governance.
Key Benefits:
Users can no longer save Style Books that accidentally combine tokens from different themes, avoiding visual inconsistencies and design regressions.
Every Style Book now visibly shows which theme it belongs to, reducing errors and making it easier for teams to manage design assets across multiple sites.
When applying a Style Book to a page, the system will only list those created with the same theme as the page’s current one—no more trial-and-error or guesswork.
If a Style Book becomes incompatible with the applied theme (e.g., after a theme change), it will be automatically unlinked to prevent display issues.
During platform upgrades, existing Style Books are automatically linked to the site’s current public theme (as defined in Site Builder > Pages > Options > Configuration), reducing manual cleanup work.
If a Style Book is imported without a valid themeId, the user gets a clear warning and knows exactly what’s missing to fix the import.
Style Books based on themes that are no longer deployed or no longer provide a valid frontend token definition are automatically marked as inactive—clearly flagged and non-selectable.
The OSGi or themeCSS client extension ID is displayed for inactive Style Books, helping devs or admins identify which theme needs to be re-installed or fixed.
With the release of Liferay DXP 2025.Q2, we are deprecating the Elasticsearch 7 compatibility due to the end-of-maintenance and upcoming EOL of the Elastic Stack 7.17. Liferay strongly recommends all customers with 7.17.x or earlier deployments to upgrade to the latest compatible version of Elasticsearch 8.x. Learn more.
Usamos cookies para mostrar contenidos personalizados, analizar tendencias, administrar el sitio, llevar un seguimiento de los movimientos de los usuarios en el sitio y recopilar información demográfica sobre nuestra base de usuarios en su conjunto. Acepte todas las cookies para disfrutar de la mejor experiencia posible en nuestro sitio web, o bien administre sus preferencias.
Consulte la Política de privacidad