Liferay Portal 7.3 CE GA5 Release

We are happy to announce the release of Liferay Portal 7.3 CE GA5!

We are happy to announce the release of Liferay Portal CE 7.3 GA5, this is our fifth 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 many new and very interesting 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. The next section provides instructions on how to download the docker images for the new release.

Download options

Docker images

We have published an official docker image for this release on Docker hub that you can use to deploy Liferay Portal 7.3 CE GA5 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.4-ga5

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 require 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, you will only need to define a single dependency artifact by adding the following line to each modules build.gradle file:

dependencies {
   compileOnly group: "com.liferay.portal", name: "release.portal.api"
}

It is now possible to use the single dependency with target platform meaning during an upgrade it will be possible to update all dependancies to the new version by updating the target platform properties in the projects gradle.property file:

liferay.workspace.target.platform.version=7.3.4

When using an IDE such as Eclipse or IntelliJ all apis are immediately available in autocomplete for immediate use. 

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.

Consistent Branding

With Style Books, UX Designers can elaborate their Design Systems 

The need for a “Style Book” goes hand in hand with the need to have “design systems” where branded solutions can be scaled with efficiency, while design and experiences remain consistent. The new Style Book Editor aims at bringing order by reducing inconsistencies, and disconnected experiences that site users may have when multiple page creators work in parallel to create new experiences. It is composed of a set of styles and style rules represented by CSS variables (also called Tokens) that can be reused across pages within the same site.

With Style Books team members are allowed to create, edit and share customizable Style Books reinforcing the company brand, making important elements such as element styles, fonts, theme colors, and style rules accessible and common for content authors (including Marketers, UX Designers, Team members, etc.). Common Style Guides will be made available across all sites under a virtual instance, easy to modify while giving the option to Marketers to pick a design conforming to the corporate image and/or service brand.

The Jira ticket for this feature is LPS-98586

Tailored Responsive Layouts

Design the responsive behaviour you’d like for Layouts

The ability to create a responsive design is a must have today when looking at the wide and increasing variety of device screen sizes accessing the same source of information. The out of the box fragments are natively pre-configured to be responsive depending on the size of the browser window (or its viewport to be precise), but page creators often need to adjust and fine tune the behaviour for mobile or tablet devices.

The Grid fragment allows creating custom layouts by either defining a number of modules per row or defining a custom layout. Now a page creator can define different responsive layouts for mobiles and tablets.

The Jira ticket for this feature is LPS-98712

Collection Pages

Facilitate and speed up the creation of pages for collections

A very common scenario for public websites is to create pages that display a list of content or some other items. Examples of this could be “Success Stories”, “Products List”, “Team Members”, etc. Liferay like most content management systems supports this, although it requires several steps.

The goal of this feature is to make it easier and speed up the creation of pages for collections. A marketer and any non technical user can create a new collection page from any existing collection of content (or create one on the fly) and then leverage the Collection Display fragment to have full visual control over how the items of the collection will be displayed.

After creating a Collection Page, a content author will be able to add additional Collection items directly from the page, navigate through the collection items and view the item’s details with their corresponding Display Page. 

The Jira ticket for this feature is LPS-98700

Allow System Admins to disable freemarker templates

Liferay supports the use of Freemarker in fragments in order to provide fragment developers with a strong templating system to create the HTML code of the fragment. Using freemarker is not mandatory and not necessary for simple fragments, but it's an option always available for developers.

Similarly, Freemarker is also supported to create Web Content Templates and Widget Templates (aka ADTs).

In some scenarios, however, it's not desired to give this possibility to fragment developers since freemarker code can potentially have a negative impact on the system since it's so powerful.

This feature gives System Administrators the option to disable the usage of freemarker across all virtual instances of the installation, while limiting the provided functionality as little as possible.

The Jira ticket for this feature is LPS-115589

Align the sidebar designs for widget pages and content pages

In previous releases we optimized the space of the fragment panel for content pages. Now we also have done it for widget pages. The new widget panel optimizes the space of the fragment panel description elements, and opens the door to bring more relevant info to the end user of widget pages.

The Jira ticket for this feature is LPS-115589

Re-organized fragment sidebar

The common fragment style list has been made accessible separate from the Fragment Configuration. To permit this, we optimized the cumbersomeness of the sidebar, re-arranging in a more user friendly manner.

The Jira ticket for this feature is LPS-116989

Extended categorization capabilities

Create vocabularies for internal use only and leverage the potential of systematic categorization

Content categorization can be carried out in many ways and for many different purposes. For example, content that is created for marketing purposes have specific requirements in terms of metadata, so it can be tracked, searched and reused whether by content teams or other areas of the organization. In these cases, having vocabularies that are only visible in the administration side can facilitate sorting, findability and reuse of contents.

In this epic, we are adding a new configuration to vocabularies in order to let users decide if they are for external or internal use. We are also providing two new out of the box vocabularies on the global site, which are inherited by all the sites to facilitate their cross-cutting use. The Audience and Stage vocabularies will empower the content creator and marketing strategist in the execution of their content strategy, by allowing the auditing of content in the Content Dashboard.

In addition, the globalTopic vocabulary is also generated and its management is centralized in this site.

And last but not least, we had time to do some improvements to usability when managing vocabularies and categories. We hope you’ll enjoy it!

Out-of-the-box Global Vocabularies

Select and create categories

The Jira ticket for this feature is LPS-111333

Content audit Graph

Get insights on your content strategy execution

To further enhance the possibilities that Liferay offers to marketers and content authors, we have provided the Content Dashboard already included in the GA4 with a graph that makes it easy to audit a company's content. To conduct a content audit, simply select the two global vocabularies you want to see represented on the chart, and the graph will automatically calculate the number of existing assets for each category of the featured vocabularies. 

You can also use the filters available in the list (categories, tags, authors, asset subtype, site...) to adjust the volume of assets represented in the graph.

You can take a look at the Jira ticket LPS-111329

New filtering capabilities in the Content Dashboard

Search and find content across all sites easily 

In the previous release, we added a tool called Content Dashboard to help users manage their content. It aims to be a one-stop-place where content authors will be able to access all the content generated by them, not only for a given site, but for all the sites and asset libraries in a Liferay instance. As the all-content-view in the content dashboard can be overwhelming, considering that all web contents of any instance will be displayed, a good set of filters is needed. Filters featured in the management tool bar will provide filtering and ordering capabilities that will apply to both list of content and audit graph, to help users to easily find and audit the contents they need. 

All the filters implemented in the Content Dashboard allow the recovery of assets across all sites and asset libraries in a single query. These filters are: 

  • Status

  • Author

  • Content Subtype

  • Category

  • Tag

  • Site and Asset Library

 

The Jira ticket for this feature is LPS-114181

InfoPanel in the Content Dashboard

All content’s metadata in just one click

Most of the relevant information about the web contents featured in the Content Dashboard is set in the columns displayed. But there is much more metadata that can be interesting for the content author, such as the version of the content, all the categories applied or the languages it is translated into. All this information is displayed on the InfoPanel simply by clicking on the "Info" option of a content.

You can see the Jira ticket LPS-113907 for more information about this feature.

Use Structures stored in Asset Libraries to create content in Sites

Asset Libraries were introduced a couple of GAs ago to help teams organize content  that needs to be reused across sites. Now they cover another very common scenario, where you need to create content using the same structure in different sites. Now it is possible to expose the structures stored in an asset library to be used to create content in the connected sites.
LPS-105949

Mapping of SEO and OpenGraph tags in display page templates

Display pages allow showing assets like web content, documents and blog entries using all the power from the fragments tools. And one display page template serves multiple content. When sharing these pages on social media, marketers would like to choose which info to show, which description or image. Being dynamic means that each asset should have its own messaging.

In order to allow that, now it is possible to map the OpenGraph and SEO fields to any field of the assets, choosing the most appropriate field. LPS-114601

Import/Export of web content for translations

For content-heavy sites and presence in multiple markets, translations are done with the help of external agencies or freelancers that use dedicated software to provide the translations.

Now Liferay allows the possibility to select the content to be translated and export the needed languages in the standard format for translations (XLIFF, either in 1.2 or 2.0 versions), then these files can be sent to the translation agency. After the translations are ready, the files with the translations can be imported in Liferay to include the translations with the original content.

Platform Improvements

Allow embedding additional content in the responses

In the headless APIs there are endpoints dedicated to different entities that make sense. For the linked elements (like rendered content, or documents attached to structured content), we provide what we believe is the needed information, but in some cases, a developer would like to retrieve in the same request all the information from the linked elements.

Now the APIs allow embedding in base64 the binaries of documents as well as the rendered content of structured content using the “nestedFields” param. This feature is available both for GraphQL and REST. LPS-90751

Create, update and delete navigation menus through an API

Navigation menus were exposed previously through the APIs, but now it is also possible to manage them completely from the APIs.

CORS configuration on instance level

This feature allows to configure CORS settings on instance level. The way to configure on instance level remains the same as at system level.

The new CORS infrastructure will try to match url patterns that are configured at instance level first, then try to match url patterns that are configured at system level, meaning if there are same url patterns, those configured at instance level will take precedence.

LPS-111617

OAuth 2 configuration on instance level

For instance level administrators, the OAuth 2 application scopes screen has been simplified. There is no longer any indication of which API application a scope relates to. This means the portal level administrators have more control over the presentation of scopes to the instance level administrators and also end users when they are presented with application authorization requests. For example, two scopes relating to two separate API applications can be presented on UI as if they are one. 

LPS-105158

Authorizations for OAuth2 applications have an expiration period. An authorization is considered to be expired when the refresh token expiration date is prior to the process execution date, if the authorization does not have this refresh date, the access token expiration date will be checked.

After expiry, authorizations data is still kept in the database even though this can no longer be used.

Now an expired authorizations afterlife duration can be configured. After the expired authorizations afterlife duration the authorization data is automatically removed by a scheduled process running in the background.

LPS-105156

OpenId Connect configuration on instance level

From now on, it is allowed to configure connections to different OpenId Connect providers for each instance.

The option to configure an OpenId Connect Provider on system level is still available. When one is configured on system level, that is visible to all instances, acting like a default OpenId Connect Provider. And when one is configured on instance level, that is only visible to that same instance.

LPS-105151

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

Blogs

I upgraded our microsite to GA5 and I noticed one problem - all the Web Content structure fields are gone from Fulltext Index and they are just a part of a common "content" field that stores all the fields merged together. In GA4 and all the previous versions, they were represented as a separate field called something like "ddm__[keyword/text]__[structure_id]__[field_name]_en_US_Number_sortable".

 

We used it heavily to do searching and sorting in custom portlets since the times of Liferay 6.2 and since 7.3 we use it also with the new Custom Filter Widget.

 

I'll do some investigation around it tomorrow to find the actual code change but I hope that's just a bug, not an intentional change. Otherwise, please put it back in the index, we really need it :)

 

All the rest seems really nice, we'll keep testing the new features in the next week.

Hi Krzysztof

 

It isn't a bug, it is an improvement to avoid issues in Elasticsearch related to

"Limit of total fields has been exceeded" see  https://issues.liferay.com/browse/LPS-103224

 

Now, the ddm_* fields are stored as a nested document called ddmFieldsArray, more information see this breaking change:

   - https://github.com/liferay/liferay-portal/blob/master/readme/BREAKING_CHANGES.markdown#dynamic-data-mapping-fields-in-elasticsearch-have-changed-to-a-nested-document

 

For now, you can activate the "legacy" behavior from  "System Settings" => "Dynamic Data Mapping" => "Dynamic Data Mapping Indexer"

 

I am going to investigate how to use the new ddmFieldsArray in the Custom Filter Widget .

Besides the custom filter widget, are you using this ddm fields in a custom code or anywhere else? Thank you,

Jorge

Hi Jorge,

Thank you very much for your reply. I installed Kibana and looked closer to how it's done right now and unfortunately, it seems to be much more difficult to use than before.

 

{

  "ddmFieldName": "ddm__keyword__77955__Year_en_US",

  "ddmValueFieldName": "ddmFieldValueKeyword_en_US",

  "ddmFieldValueKeyword_en_US": "2010-01-01",

  "ddmFieldValueKeyword_en_US_String_sortable": "2010-01-01"

}, {

  "ddmFieldName": "ddm__keyword__77955__SessionNumber_en_US",

  "ddmValueFieldName": "ddmFieldValueKeyword_en_US",

  "ddmFieldValueKeyword_en_US_Number_sortable": 36,

  "ddmFieldValueKeyword_en_US": "36"

}

 

I don't see a way how could it be used in Custom Filter widget because each search and aggregation should be run on two different fields at the same time - ddmFieldName for the actual field name and ddmFieldValueKeyword_en_US for the field value.

 

I'll continue testing next week, have a great weekend :)

KG

 

For the record: there is a typo in my previous comment: the nested document field is called ddmFieldArray (singular) instead of ddmFieldsArray

Where exactly do I have to set the platform version ("liferay.workspace.target.platform.version=7.3.4")? So far I do not have a gradle.properties file. I have a build.gradle and a settings.gradle in my root folder. In the root folder there is a folder modules with my Portlets/Services/Apis.

Another great GA with lots of new features. The major issue I foresee is that the platform is exploding in complexity and is spreading itself thin. It still seems to be getting less and less intuitive by the day and I can't see how documentation can keep up. For developers and admins I can see this huge mountain in front of us, struggling to find use cases for these features.

 

Evaluating and providing feedback on the GA's is actually becoming impossible because so much is changing and the changes are not being documented enough for us to evaluate if the feature is, good, bad, neutral and if we should care about it.

 

It's a LOT of information to process within a few weeks.

 

I don't think Liferay is being designed for real world content creators. It seems that 90% of this stuff is way too complex for the average user. Take the responsive columns, it is great that users could rearrange their layouts for mobile devices. Will they? Most likely not no, that's a lot of design considerations to make that the average user will not want to do. What we'd need there are layout templates so that columns auto flow downwards to fit the space. I don't have the time to teach content creators good mobile design and they won't care about it either.

 

Our users I think will struggle even more under the weight of Liferay. Content creation is not their sole job, infact it's mostly a side thing that they have to do. It's a secondary task of their job to put content on to the Intranet and that's why getting copy and paste from Word to work correctly is so much more valuable than content pages ever would be.

 

I really don't think that as Liferay developers and system admins we are the right people to give feedback on these features. Give these GA's to content creators directly and I think the problem of usability will become too obvious to ignore.

 

Lee Jordan added some good points here.

Most of the time our customers want us to setup the initial content - because it's just to complex to teach some office-secretary how to fill Liferay with content.

 

All our fragments, webcontents need to override fonts and spaces applied by Microsoft Word all the time - because at a minimum one time a customer will copy paste text from Microsoft Word directly into Liferay.

 

We even started to hide features - simply by hiding with css - in the backend to move things the customer doesn't want to use or doesn't know about out of his way.

 

If we would not do that a customer is trying to place the Liferay Knowledgebase on a Content Page and Boom: Not working. Why? Because it's not working on content pages on 7.2. 

We don't want to test everything - so we better hide features that MIGHT not work.