This is our fourth GA for 7.3 this year following the new rolling release cycle that we adopted and announced earlier this year.

As with previous GAs, this new release is adding several very interesting new features based on our roadmap and includes improvements based on the feedback that we have received from the community.

This post introduces the highlights included in this release. For those who can’t wait, the next section provides instructions for how to download the docker images to try out the new release.

Download options

Docker images

If you are not the kind of person that reads the instructions of a new gadget you have bought or of a new software you’ve just downloaded, If you prefer to just take the plunge, run the new version and try to discover by yourself the new features, we want you to do it quick and easy with docker.

Maybe you have read all the new features described in this post, and want to upgrade to the latest version, but you are running your installation on a dockerized environment.

We have published an official docker image for this release on Docker hub that you can use to deploy Liferay Portal 7.3 CE GA 4 on any system that is running Docker. If you are already have docker on your machine, you can easily get this new release up and running by executing the following command in your console:

docker run -it -p 8080:8080 liferay/portal:7.3.3-ga4

If you are not familiarized with running Liferay docker images, but you would like to try it, you can find more information on configuration options on the overview liferay portal docker page. 

Bundles and other download options

If you are used to binary releases, you can find the 7.3 release on the download page.  If you need additional files (for example, the source code, or dependency libraries), visit the release page.

Dependency Management

If you are developing on top of Liferay Platform, and want to update your workspace to use de dependencies from this last version, you will just need to use a single dependency artifact. Just add the following line to your build.gradle file:

dependencies {
   compileOnly group: "com.liferay.portal", name: "release.portal.api", version: "7.3.3-ga4"
}

All portal dependencies are now defined with a single declaration. When using an IDE such as Eclipse or IntelliJ all apis are immediately available in autocomplete for immediate use.  

New Features

New Applications Menu

New menu to separate cross-site applications and system settings

As we grow Liferay DXP, we see more and more customers leveraging multiple sites and needing ways to easily manage content, documents, and data across the entire system in a centralized manner while still retaining site-level scoping for distributed administration.

Liferay DXP has always relied on a combination of site hierarchy and the global site to empower centralized administration. Although this gets the job done, over the years, we have seen several drawbacks of this approach; properly setting up site hierarchies requires foresight, is difficult to adapt to evolving use cases, and the relationships become difficult to maintain and track as the system expands.

To alleviate these shortcomings, we have started introducing applications that work across sites, such as workflow, forms, and the commerce applications. However, we didn’t have a great place to house these applications. Because of how Liferay DXP has evolved, we have had a site level application menu and control panel to configure system level settings (cross-site). For the last few versions, we have been using control panel to house these new cross-site applications and it has become a challenge for permissioning and access control.

 

For this reason, we have created a new application drawer that houses cross-site applications. What we are releasing in this version is an initial iteration and we hope to evolve it in coming releases. The old product menu behavior can be reverted within system configuration. We hope to evolve more applications to work across sites to better support central management of content, digital assets, and experiences.

We can enable or disable the Global Apps Menu from Instance Settings > Navigation

Experience Management

We are continuing to empower designers and marketers to create engaging experiences and give them the tools to have increased autonomy as well as a more agile collaboration with developers. Here are some of the new features you can find in this release.

Save ongoing work, and revert mistakes

Page Editors can revert changes with Undo/Redo when editing a Page

When a user makes a mistake on a page, such as accidentally deleting a fragment, or removing some text or content mapping, there is a need to undo the changes and go back to a previous state.

To improve the creation experience and allow the users to correct a mistake, we have added undo/redo capabilities to the page editor that keep track of all interactions made by a user during the edition of a page. 

The user is able to undo as many actions as desired (up to 100) in the reverse order in which they were made. The user is also able to see a timeline of recent changes and could undo several actions at once.

New buttons are added to the toolbar that make it possible to undo/redo the actions. Keyboard shortcuts are also available: CMD + z / CMD + shift + z (MacOS) Ctrl + z / Ctrl + shift + z (Windows, Linux)

The Jira ticket for this feature is LPS-98693

Fragments are auto-saved as drafts

This feature ensures that the ongoing development of a developer working on a fragment through the fragment editor UI is never lost, even if the session times out, or if the fragment editor window is closed. To achieve this, we implemented fragment auto-save in the fragment editor, so that the progress is saved automatically seconds after the user edits something. This way, all changes are saved as a draft, and aren't public until the user clicks on the 'Publish' button. As a consequence of the implementation of auto-save, we removed the 'Save as draft' button, as it is no longer necessary to do it manually. As part of this story we have also implemented the ability to have a draft version of a fragment while a previous version is published and can be used by page authors.

You have more info at the JIRA ticket for this feature: LPS-114145

Advanced Fragments Capabilities

Fragment Compositions

With the new capability introduced with fragments of fragments we gave the possibility to assemble fragments from fragments with endless combinations. With Container Fragments we wanted to provide this capability of creating and reusing fragments to non-technical users as well that will be able to do that visually using the new container fragment located in the page editor.

Fragments Container

Besides being able to nest containers, the container has the following styling capability: padding, margin, background color or image, border radius, and shadow.

Note: Please note that instead of creating a new fragment to introduce these new capabilities, we decided to grow them on top of the existing  “Section” fragment and renamed it to “Container”. The new name more clearly shows that it doesn’t have to be a main page section, but can be used by anyone in the page. It’s even possible for  containers to include other containers.

More info in the JIRA ticket: LPS-112971

Advanced control over the display style for Collection Display

In the previous release, we introduced the Collection Display Fragment to provide the page creators with a way to display and define the visual style for a collection. The Collection Display Fragment allows selecting existing Collections and Collection Providers in order to display them. 

Now, we have improved it to provide a higher degree of control on the look and feel of a collection by using templates. 

In particular it is now possible to select two types of templates for a collection Display Fragment:

• List template: Determines how the list itself will appear. It could be a table, a numbered list, an unnumbered list, … We offer several out of the box list templates and developers can create their own with a provided API (InfoListRenderer).

• Item templates: Determines how each item in the list will appear. This allows reusing existing templates (for example in the case of Web Content) in addition to the existing capability of choosing how to display a content with fragments and mapping.

The related JIRA Ticket is LPS-111533

This improvement means that Collection Display Fragments not only work for any type of content that supports mapping but now, also works for content that has some template available.

Displaying collections of content types that leverage Liferay’s Asset Framework

In addition to that we’ve enhanced Display Collection to support displaying lists of AssetEntries. This will make  things even easier for those upgrading from previous versions of Liferay:  if your custom content type was already using Liferay’s Asset Framework, it will automatically work with the Collection Display fragment. In particular, it will be possible to map any of the generic fields of an AssetEntry and it will be possible to use any of the pre-defined templates (abstract, full content, …)

As a result of this change, it is now also possible to use the four generic collection providers provided out of the box which relied on AssetEntry as a way to provide a mix of several content types: Most Viewed Content, Highest Rated Content, Related Content and Recent Content). 

This work has been done under the JIRA ticket LPS-114769

New multi-level navigation widget templates out of the box

Also, an useful improvement for Site Administrators is that now Navigation Menus default templates can show more than 2 sublevels. This work has been done under LPS-113994

Distribute and re-use page templates across sites and environments through export/import

Liferay provides visual tools to create pages from fragments and widgets. Page creators may need to re-use, distribute or move them on a different site (or environment). This will allow them to capitalize on the efforts to create the pages, and improve the team collaboration. A UX Designer could, for example, draft a page and share the pages with a web developer to add custom applications and re-import them to the site. A second example, is the case of a web designer importing page templates on various sites.

This is now possible thanks to the page export function that uses a well defined JSON format (with an associated JSON schema). It allows checking it into a source control system or even enabling developers to author fragment-based pages declaratively, make modifications to exported pages and validate the result before importing them. 

The fragment-based page definition file contains all the information necessary to reproduce a page and page template. That includes the page structure, fragments, widgets and their configuration. The references to the fragments are external codes and not internal ids, so that if the fragments have themselves been exported and imported into a different system, this still works.

The Fragment Toolkit supports authoring the fragment-page JSON file. The export format follows the open JSON format defined for page definitions plus a second file for display page-specific metadata. A JSON schema validates the format. This allows developers to make modifications to the JSON files without having to import them into Liferay.

This feature has involved a lot of work, as you can see at LPS-97864

Intuitive experience for Page Creators and Editors.

As we have more and more users using fragments it became necessary to provide more textual information about the fragment, how to use them. The information about the fragment is today solely conveyed by its thumbnails that are not always provided by fragment developers, resulting in having many fragments with the same default icon. As we plan to continue adding fragments info it became obvious we needed to reduce the size of the fragment icon to generate more space. It’s also nice looking, according to users.

Now the new fragment panel optimizes the space of the fragment panel description elements, and opens the door to bring more relevant info to the end user of fragments.

We have also added the available widgets in the same panel along with fragments. That way they are both closer together. We have even merged their search, so you can now search for a specific element by name, without having to think first if it was a fragment or a widget.

You can check LPS-113509 for more details.

During page edition, the user may either have full edit permissions on a page or just have permission to edit its content (inline or mapping). When the permission is limited to editing the content, the page editor automatically enters a "Content Authoring" mode that offers limited options and provides an optimized experience for content editing. When the user has full edit permission, the page editor automatically enters a mode that offers all of the design options in addition to content authoring. We have identified, however, that in some situations, users with full edit permissions just want to focus on editing the content on the page and it would be more convenient to do so in a "Content Authoring" mode that enables more focus on the task.

The users can now choose the desired edit mode or switch between them within the page editor. The "Design mode" allows changing all aspects of the page, while the "Content Authoring" mode allows editing the inline text, changing images, etc (exactly what a user with only the "Edit Content" permission can do).

All the work for this feature is tracked under LPS-114244

In any case, page creators will also have a way to preview a page that is being edited without necessarily publishing it. It is now possible to preview the pages at any moment. This is done under LPS-114843

Finally, if after creating the pages, the Site Administrator needs to reorganize them, they can move multiple pages by selecting and dragging multiple pages in Page Administration.   

Although it is allowed to select more than one page for deleting them, moving them together by drag and drop was not possible. This feature came from a feature request, registered for development as LPS-114843, and will allow users to move more than one page at a time with drag and drop after selecting them. 

URL management

URL design is important for SEO and other reasons, and we have continued developing and improving the tools provided by Liferay Portal so that administrators can manage URLs easier and better.

As part of that process, now users can easily check the friendly URLs previously used in any page for each language and manage them visually, either forgetting URLs to be reused in other pages or restoring old friendlyURLs in case of a mistake or after finding that the new one is not performing as well as expected.

The details of this task are written on LPS-114600

Redirections management

But this is not the only improvement regarding URL management, we have also implemented some enhancements to allow Site admins to reduce errors that might appear while managing tens or hundreds of redirections: validation on the source and destination URLs, detection of redirection chains, or informing users about the effects of modifying permanent redirections are among the improvements included. You can check the details at LPS-113484

A new Content Dashboard

In this release, we have added a tool called Content Dashboard, to help users manage their contents.

The new Content Dashboard aims to be a one-stop-place where content authors will be able to access all the contents generated by them, not only for a given site, but for all the sites and asset libraries in a Liferay instance.

You can access this content dashboard through Global Menu > Applications tab.

 

As this is the MVP, only Web Contents will feed the Content Dashboard. It will be possible to search by title, order by last updated and have quick access to view or edit the content details. In the upcoming releases more features will be added to this Content Dashboard, improving its utility, but for now you may find it useful as it is.

The development of this dashboard has been done under LPS-101148, in case you are curious.

Page Performance Improvements

We always care about improving the performance of how pages are rendered, and in this case, we have disabled the validation of fragment configuration at render time to make pages render faster.

Also, we have disabled by default the ContentTrasformerListener as it was not relevant anymore for the majority of users and it may affect the performance 

Platform Improvements

Besides all the described new features and improvements there are also a bunch of other changes that may not be visible immediately for usual users or during the first revision of the new release. 

Let me guide you through a set of other features that you will probably find useful. Most of them are related to the APIs and headless features that Liferay Portal platform has.

The first of these features about APIs, is about the information exposed through APIs.

Improvements to the Content Delivery API

Exposing Metadata in Documents & Media APIs

Now the APIs do not only expose the basic fields of documents, but the whole set of metadata included in document types. Those fields are exposed when retrieving document information, but also, while uploading or updating a new document, it is possible to choose which document type to use and fill the metadata information. You can check the related ticket at LPS-116134

We have also limited the number of binary files that can be uploaded in a multipart request. Now, requests for uploading multiple files will take into account the established limit for binary upload, avoiding systems to exhaust the disk space and shutdown.

Access to content templates to render web content articles with any of its templates externally

If, on the other hand, you are one of the developers that need to use/consume the Liferay’s headless API rather than extending it, and particularly, if you are using the content delivery API, you should know that, apart from exposing the structures, it also exposes the content templates stored in a site, so developers can retrieve them and render the content on their side when needed. This work is tracked under LPS-114589

API Platform improvements

Integrated API Browsers for REST (Swagger UI) and GraphQL (GraphiQL)

But maybe the biggest and more useful tool for developers that will consume LIferay Portal’s headless APIs is the integration of the Swagger UI tool into Liferay Portal to make it easier to discover the APIs available and accelerate the development and testing phases of your apps that consume headless APIs.

This Swagger UI complements the GraphiQL client that already announced in the previous GA release.

You, as developer, will benefit from the whole set of features it provides, like exploring the different endpoints grouped by entity, check the different schemas, or perform queries to test that everything is working as expected. To access it, after logging in the portal, go to http://localhost:8080/o/api and click on “Show Swagger”.

If you are already used to swagger UI, you will find this tool familiar and useful. If you haven't used it yet, you will discover that is a great way to explore, discover and try the Headless API.

OpenAPI validator

For the developers that need or want to extend the APIs with OpenAPI, and in order to improve the developer experience when working with the REST builder to implement your custom REST and/or GraphQL APIs, we’ve added an OpenAPI validator that will inform users in case there’s any format error with the input file, as well as informing of any feature in the standard that we are not supporting yet. This is LPS-101996

Liferay Workspace

Liferay Product Info Key

Liferay Workspace introduced a number of new features over the years (downloading bundles, target platform, docker integration) each of which introduced a new gradle property to represent the Liferay product you were attempting to develop for.

In Liferay Workspace 2.5.8 and Blade 4.0.0, we decided to introduce one new key that encapsulates all of them: com.liferay.workspace.product. 

For example:

com.liferay.workspace.product=portal-7.3-ga3

Is equivalent to:

liferay.workspace.bundle.url=https://releases-cdn.liferay.com/portal/7.3.2-ga3/liferay-ce-portal-tomcat-7.3.2-ga3-20200519164024819.tar.gz
liferay.workspace.target.platform.version=7.3.2
liferay.workspace.docker.image.liferay=liferay/portal:7.3.2-ga3
app.server.tomcat.version=9.0.33

ElasticSearch 7.3

Beginning with Liferay Portal 7.3 CE GA4, Elasticsearch 7.3 is now the default search provider.  The new implementation for Elasticsearch 7.x uses a new REST Client for connecting to a remote search server which means the connection will need to be reconfigured for GA4 even if the environment was previously using an Elasticsearch 7.x connector.

Also note that Elasticsearch 6.x will no longer work with Liferay Portal 7.3 E GA4 due to the change to using the new REST Client which means installing Elasticsearch 7.x is required for use with GA4.  

Documentation for configuring Liferay Portal for use with Elasticsearch 7.3 can be found here. Most of the documentation for configuring Liferay Portal 7.3 CE GA4 for use with the new REST Client still applies with the exception of manually creating a config file.   

For example a new configuration for Elastic Search 7.x called com.liferay.portal.search.elasticsearch7.configuration.ElasticsearchConfiguration.config:

clusterName="liferay_cluster"
indexNamePrefix="liferay-"
networkHostAddresses=[ \
  "http://search:9200", \
  ]
operationMode="REMOTE"
productionModeEnabled=“true"

The configuration can be checked in the Search configuration panel.  Successfully connecting to a remote server results in the following status:

 

 Documentation

All documentation for Liferay Portal/DXP 7.2 and above can now be found on our new documentation site called learn.liferay.com.  For more information on our new documentation initiative see the official announcement here.

Compatibility Matrix

Liferay's general policy is to test Liferay Portal CE against newer major releases of operating systems, open source app servers, browsers, and open source databases (we regularly update the bundled upstream libraries to fix bugs or take advantage of new features in the open source we depend on). 

Nothing has been removed from the matrix, however a couple things have changed.  Liferay Portal 7.3 CE was tested extensively for use with the following Application/Database Servers: 

Application Server

• Tomcat 9.0

• Wildfly 16.0 (Previously 11.0)

Database

• HSQLDB 2 (only for demonstration, development, and testing)

• MySQL 5.7, 8.0

• MariaDB 10.2

• PostgreSQL 11.2 (Previously 10)

JDK

• IBM J9 JDK 8

• Oracle JDK 8

• Oracle JDK 11

• All Java Technical Compatibility Kit (TCK) compliant builds of Java 11 and Java 8

Source Code

Liferay Portal CE's source is available as a zip archive on the release page, or on its home on GitHub. If you're interested in contributing, take a look at our contribution page.

Bug Reporting

If you believe you have encountered a bug in the new release you can report your issue by following the bug reporting instructions found on the Liferay Portal CE site.

Getting Support

Support is provided by our awesome community. Please visit helping a developer page for more details on how you can receive support.

Fixes and Known Issues

• Fixes

• List of known issues