Ability to set expiration and review dates for articles, and to view which articles are pending expiration.

Improved navigation through the different tabs and pages in Knowledge Base in the manage toolbar, sidebar search, sidebar primary button, priority and general interactions.

Table View is displayed in the Knowledge Base.

Now Content Editors can easily find the documents they are looking for thanks to the new filters added to Documents & Media.

Three (3) new filters have been added: categories, tags and extensions.

Page listing the version history of a document to help managing different version.

Priority icons to MB CSS are added to avoid to force enabling font awesome in the whole portal.

We have made the organization’s addresses, phone numbers and email addresses changes tracked. These can be added to a Publication from now on.

The list of working in progress for Publishing features can be found at Publications update 2023/06/13. We have improved performance, while also making the wiki pages change tracked. It has also been implemented a mechanism to remove publications that are more than 6 months old.

This new feature allows content editors to view the only publications that included modifications to a particular asset.

With this new feature an admin should be able to help preconfigure a publication to help facilitate their unique workflows.

Publication templates can be leveraged to provide naming patterns to any created publication. Tokens are provided to allow each publication to have unique names.

Admins can also assign roles to users immediately during publication creation.

Users can now create, edit, or delete knowledge base articles within a publication.

Publications can take up quite a bit of space in the database.  While some users need an extensive history, others do not.

With this new feature we can provide an optional clean up to remove older publications for those who do not need the history.

Users can preview the changes of a wiki page within a publication.

We have refactored Ongoing, Scheduled and History tabs to use dataset display, and added a configuration to speed up review changes screen.

Operating Liferay (on-prem!) with Elasticsearch 8 as a search engine leveraging its REST API compatibility mode through the bundled Elasticsearch 7 connector allowing Liferay deployments to upgrade the Elastic Stack to 8.x (opt-in), while also keeping compatibility with 7.x.

General Upgrade Instructions:

Please refer to the documentation for more details.

1. No action is required for deployments already using and insisting to stay on Elasticsearch 7.
2. Moving to Elasticsearch 8 may require a full reindex depending on the choice of the upgrade path:
   1. Upgrading the current Elasticsearch 7.x cluster to 8.x and connect DXP (Upgrade Elasticsearch | Elasticsearch Guide [8.10] | Elastic , recommended) → No reindex required
   2. Setting-up a new Elasticsearch 8.x cluster, connect DXP → Reindex required!

This is not a new connector, but enhancements to the existing bundled Elasticsearch 7 connector and other Elasticsearch-only features (like Commerce, Workflow Metrics or Search Tuning) leveraging the REST API compatibility mode of Elasticsearch 8 servers.

Liferay Portal 7.4 CE GA78 and Liferay DXP 7.4 Update 78 Tomcat Bundles and Docker Images come with Elasticsearch 7.17.10 for Sidecar.

Support for Object displays pages in the search results, aggregating (via Custom Facet widget), filtering (Custom Filter widget) and sorting (Sort widget) using Object fields that are indexed as Nested Fields in Elasticsearch, similar to Web Content Structure (DDM) fields.

Automatically register a collection provider for each search blueprint. By displaying the blueprint's results in a collection display fragment, you can leverage search to return your assets dynamically, and reap the benefits of the fragments toolbox to lay out the page.

Search the company index for matching content through a single endpoint and build custom search experiences. Supports facets with translated display terms and also custom searching, filtering, aggregation and sorting through Search Blueprints (DXP ONLY)

Liferay Portal 7.4 CE GA88, Liferay DXP 7.4 Update 88 bundled with the latest available version of Elasticsearch 7.x for Sidecar (7.17.12, as of Aug 7, 2023).

With this new front-end client extension users will be able to add an entry to the global import map.

This can be used to share code between decoupled client extensions that are freed from the need to know the deployment URL of the code at build time. For example, this will allow you to share your library or framework of choice among all your front-end client extensions:

For a script to consume the JavaScript module referred to by the import map entry, it needs to be of type=module.

In order to help developers to understand how to use this client extension, a sample has been provided: https://github.com/liferay/liferay-portal/tree/master/workspaces/liferay-sample-workspace/client-extensions/liferay-sample-etc-frontend-2

This new frontend client extension allows users to replace the existing theme spritemap without the need to redeploy a theme. The spritemap should include all icons needed for the scope where it is used.

The Control Panel still uses the admin spritemap.

After registering the client extension, in the page template or page you need to use it, configure it from the design options menu:

To enable this client extension, do it from the Feature Flags management UI:

This feature allows developers to create or update an object and its related elements in a single request, optimizing the requests performed to the server, thus improving the overall performance of your solution.

Provided the necessary data for the related elements (ExternalReferenceCode, Id, etc), if the element already exists, it will relate the two objects, if the related element does not exist, it will create the object and it will relate them.

It is also possible to remove related elements by just updating the parent without the elements that are not related anymore.

Now, developers will be able to filter Custom Object Entries using the field values of the related elements for a given Object entry.

It is possible to filter as many levels as needed. The format of the filter query needs to be: relationshipName1[/relationshipName(i)]*/fieldNameN. Being relationshipName1, relationshipName(i), etc the different relationship names that join Object 1 with Object i, and fieldNameN being the name of the field of the latest Object definition on which the user wants to filter.

In addition to this, our nesting capabilities have been enhanced, so now it is possible to retrieve data for an Object entry and its related elements, supporting several levels of nesting.

The names of the different relationships to retrieve need to be specified in the nestedFields parameter, separated by commas. Additionally, the nestedFieldsDepth parameter with the number of levels to retrieve needs to be specified in order to indicate to Liferay how many levels it is necessary to nest.

It has extended the support for External Reference Code to other Liferay entities in version 7.4. With this new parameter, users will be able to access, create, update and delete various entities by simply specifying the scopeKey and the external reference code.

This External Reference Code is a custom identifier, which means that at the creation time it can be set, helping to migrate entities from one environment to another while keeping this External Reference Code the same across environments. You can check the available endpoints to be accessed by External Reference Code in the API explorer.

The batch engine API allows developers to export/import data, but it requires developers to provide a configuration with multiple parameters. With the new auto-generated endpoints, it is easier to perform export operations in the portal. The export endpoints are asynchronous, so it will provide a taskId in order to retrieve/download the records requested.

The endpoints follow this format:

Now users can manage the tags and categories associated with the Objects entries from the REST APIs. When an Object has Categorization enabled, properties for tags and categories will be exposed in the Object entries schemas. Users can retrieve the information, set or update the tags and categories associated with the Object entries as well as use the information of these fields to filter information

Now it is possible to manage and check the permissions of the object entries directly from the headless APIs.

For each object definition, two new endpoints are available. One to retrieve the permissions that apply to that individual Object entry and another one that allows users to set/update the permissions that apply to that entry.

Now it is possible to use all query parameters available from the API explorer. Parameters such as fields, nestedFields or flatten are accessible and ready to use in your test queries.

With this feature it is possible to differentiate the login failures in the audit messages, which one is caused by incorrect password and which one is caused by incorrect login.

Before this change, audit messages were only returned for cases when the authentication failed with FAILURE status, which happens when the user provides an incorrect password. The event type is LOGIN_FAILURE in this case.

With the new changes, it is provided audit information for cases when the authentication fails with DNE status by adding a LOGIN_DNE event type. DNE stands for user "does not exist", it always means that the login (email / screenName / userID) is incorrect.

So with the newly added LOGIN_DNE event type we cover authentication DNE scenarios when the login fails due to incorrect login (email / screenName / userID) .

When the users are authenticated through SSO and IdP, it is possible to remove the ability of the end users to add or edit their passwords.

As an Instance Administrator, you are able to configure if the users have the option to give their password at registration and you can remove the whole password block from editing user data, if the password is not changeable by the password policy of the user.

The instance administrator can create email templates including the first name.

With this new feature, Instance Administrator can export audit data filtered by user as well as filtered by site. They can also store site data for audit events.

We display some additional messages to Site and Site template Administrators when there is a Friendly URL collision between Site page and Site template page.

From now on, users can view the summary of failed staging processes, which can help them to solve the issue(s) which caused the staging process to fail.

Using LAR files for export/import in the portal are stored in DM. These LAR files can increase the size of the DM significantly. We have changed this, so the LARs are not kept in the DM after the export/import process.

On LPS-136108: URLs using a virtual host are always reformatted on export and import, even in cases where they don't need to be the validation of the Web Content was added for Liferay layout URLs. Before this, there was no validation, so users could create their customizations where they could add different URLs to the Web Content's content. After the validation was added, some custom URLs became unable to be added to the Web Content. From user perspective this was a feature loss, so we decided to deliver a feature to make customers able to add their custom URLs to Web Content's content field. This feature is about adding a configuration for storing the user’s relative URL patterns. So custom URLs containing this pattern would bypass validation.

Before the Import process starts, users are now asked via a confirmation dialog if the user is sure about deleting application data . Also, we have improved the error message for Staging related references.

As a Site Template Administrator: template propagations are run completely in the background and background tasks are executed in a sequence. The LAR from the Site Template export is cached, so different Sites can reuse it.

• LayoutSetPrototypeMergeBackgroundTaskExecutor always uses the latest Template version for the propagation.
• If there is already a queued background task for the Site, we don’t create a new one.
• If there is a background task in progress, we only create a new background task if the Template was modified.

Two new configuration options were added:

• The first one gives the users the chance to automate an existing feature, which improves performance.
• The other one is about displaying the Advanced Staging configuration screen to the users, improving usability.