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.
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.
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.
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:
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:
When using an IDE such as Eclipse or IntelliJ all apis are immediately available in autocomplete for immediate use.
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.
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
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
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
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
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 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
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!
The Jira ticket for this feature is LPS-111333
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
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:
Site and Asset Library
The Jira ticket for this feature is LPS-114181
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.
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
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
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.
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
Navigation menus were exposed previously through the APIs, but now it is also possible to manage them completely from the APIs.
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.
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.
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.
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.
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.
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:
Wildfly 16.0 (Previously 11.0)
HSQLDB 2 (only for demonstration, development, and testing)
MySQL 5.7, 8.0
PostgreSQL 11.2 (Previously 10)
IBM J9 JDK 8
Oracle JDK 8
Oracle JDK 11
All Java Technical Compatibility Kit (TCK) compliant builds of Java 11 and Java 8
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.
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.
Support is provided by our awesome community. Please visit helping a developer page for more details on how you can receive support.
List of known issues
Looking good so far!
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.
It isn't a bug, it is an improvement to avoid issues in Elasticsearch
"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:
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 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.
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 :)
Hi Krzysztof GołębiowskiSearch team has opened https://issues.liferay.com/browse/LPS-123694
to handle this problem with the Custom Filter widget
For the record: there is a typo in my previous comment: the nested
document field is called ddmFieldArray (singular) instead of ddmFieldsArray
I used docker in mac.
An error occured,Then the server was down:
usr/local/bin/start_liferay.sh: line 3: 8 Killed
We should increase the memory to 8G.
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.
Have a look to:
- Setting the Target Platform: https://help.liferay.com/hc/es/articles/360028834272-Setting-the-Target-Platform
- Targeting a Platform Outside of Workspace: https://help.liferay.com/hc/es/articles/360028834292-Targeting-a-Platform-Outside-of-Workspace
In the second link there are instructions about updating the
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.