The vendor has deprecated OpenSSO/OpenAM, so there's no reason for us to keep it. The alternative, which is PingAM can be integrated using our existing OpenID connector or SAML Authentication.

The SSL Certificate Management view now provides expiration alerts for certificates nearing expiration (e.g., within 30 days) and those that have already expired. Certificates must now be defined exclusively through the LCP.json file, simplifying management and ensuring consistency across deployments. This update reduces manual errors and ensures secure and uninterrupted deployments.

Highlights:

• Expiration Alerts: Notifications for certificates nearing expiration and those already expired, with clear visual indicators.

• Exclusive LCP.json Configuration: Certificates can only be defined through the LCP.json file.

• Improved Visibility: Organized list view showing certificate names, types, associated domains, and expiration dates.

• Proactive Management: Tools and alerts to help users maintain secure SSL/TLS configurations.

The Marketplace release of the Liferay Connector to OpenSearch 2 provides an alternative to Elasticsearch for Self-Hosted Liferay deployments.

This connector integrates Liferay DXP with OpenSearch 2.12+, the open source and enterprise grade search engine. OpenSearch offers lexical search for text data, robust scalability and extensibility, and vector search for applications using embeddings, such as Liferay's Semantic Search.

The installation of this app requires specific configurations covered in the official documentation. For detailed compatibility information, see the Search Engine Compatibility Matrix.

The OpenSearch integration is currently a Beta feature with the intention to make it GA in the future.

Liferay Cloud now provides CI/CD support for Client Extensions on Liferay PaaS. Developers can integrate Client Extensions into their Git-based CI/CD pipelines, ensuring automatic builds and deployments alongside core Liferay services. This update enables automated validation, independent deployments, and faster release cycles for Client Extensions.

Highlights:

• Dedicated CI/CD Pipeline: Separate build pipeline for Client Extensions to prevent conflicts with core Liferay services.

• Automated Builds: Every commit triggers a new Client Extensions build, packaged as a LUFFA archive.

• Independent Deployments: Client Extensions builds deploy separately, improving release flexibility.

• Seamless Integration: Works with existing Git-based workflows on Liferay PaaS.

• Zero Downtime Deployments: Deploy client extensions without affecting the main Liferay service.

Liferay 7.4 introduces the ability to manage language translations directly within client extensions. This enhancement allows developers to provide multilingual support for custom labels and properties without relying solely on OSGi bundles.

Key benefits: 

• Developers can now define and manage language keys and translations within the client extension itself, ensuring that all labels and custom properties are displayed correctly across different languages.

• This feature eliminates the issue of untranslated labels with dashes, providing a consistent and professional appearance on multilingual sites.

• Simplifies the process of adding translations, reducing the need for manual intervention and external OSGi bundles, thus accelerating the development and deployment of multilingual features.

• Empowers developers to create more flexible and fully localized custom elements and themes, enhancing the overall versatility of the Liferay platform.

• This functionality refers to tracking events related to non-default asset types and visualizing the data on a dashboard. From now on, customers will no longer be able to use this specific method to track views of non-default asset types and visualize this data on a dashboard in Analytics Cloud

• Using custom event tracking is the recommended way to track your custom assets from now on.

We have introduced a new publication size classification feature to help users better manage and plan the publishing process, especially for "large" publications where there are many changes involved. This feature categorizes publications into three tiers: Small, Medium, and Large, based on factors such as the number of changes made and the size of the database. This will allow users to better understand the scale of their publication and take the necessary steps to avoid potential conflicts or performance issues during publishing. Publication Owners are also notified whenever a Publication has changed sizes.

Key Benefits:

• Improved Planning: With the new size classification, users can see the current "size" of their publication and allocate the appropriate time and resources for publishing. This helps avoid rushing through a publishing process that might take longer depending on the publication's size.

• Better Visibility of Potential Impact: The classification provides users with a visual indicator that highlights the size of the publication, offering transparency about what to expect during the publishing process. It also helps reduce the chances of errors or performance issues related to publishing "large" publications.

• Clear Communication: When users hover over the size classification, a helpful tooltip explains what the classification means and the potential consequences for the publishing process, ensuring users have all the information they need to make informed decisions.

When a user is deleted from DXP, the deletion now happens simultaneously in Analytics Cloud. To enable this, we’ve developed an API that automatically removes the same list of users from both DXP and AC in real time, ensuring data consistency across both systems.

Key Benefits:

• Processing Time: Depending on the number of users deleted, the process may take some time in Analytics Cloud. You can track the progress in Data Control & Privacy > Request Log under “Request Status.”
• Suppression Before Deletion: Each deleted user must first be suppressed before being permanently deleted in Analytics Cloud. As a result, you will see two requests per user—one for suppression and another for deletion.