Liferay Portal 7.3 CE GA3 Release

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


Official images can be found on Docker Hub and can be used for deployments on any system that is running Docker. For more information on configuration options for the image see the overview page. To get started with docker run the following:

docker run -it -p 8080:8080 liferay/portal:7.3.2-ga3


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

All 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.  Update the projects build.gradle file to contain the following:

dependencies {
   compileOnly group: "com.liferay.portal", name: "release.portal.api", version: "7.3.2-ga3"

New Features

Experience Management

We are continuing to empower designers and marketers to create user-friendly, beautiful and engaging experiences, without code, freeing developers to focus on advanced interactive experiences through modern front-end tooling and APIs. Here are some of the new features you can find in this release.

NOTE: We have renamed “Content Set” as “Collections” in the Site Building menu. We decided to generalize the concept to collections defined programmatically by a developer called “Collection Providers”. That’s additional flexibility to create specific collections and group assets with more advanced criteria.

LPS-113660 Support drop zones in fragments so that page creators can add any fragment or widget inside

Currently fragment developers can create fragments with HTML, CSS and JavaScript, and also embed specific widgets inside a fragment. However, in some cases more flexibility is desired since it's not always possible to predict which fragments (or widgets) will be the needed inside a given fragment.

Thanks to this new feature, it’s now possible to define a zone inside any fragment, allowing more composition options for both developers and business users.  A fragment developer can extend the functionality of their fragment by defining a certain space within it, which acts as a drop zone. In this zone, the non-technical users (Marketers/UX Designer) could include any existing fragment or widget. 

For example, a developer that provided a carousel fragment that was initially designed to uniquely show images could recycle it to allow business users to drop additional elements of their choice like text, buttons, and more.

Thanks to “drop zones” it will be possible to create advanced fragments such as a tabbed component with different content in each tab, a carousel with similar flexibility, a fragment that opens a pop-up, etc.

This feature fits into the overarching theme of empowering developers to empower non-technical/business users.

LPS-101065 Allow the creation of fragments as a composition of other fragments so that page creators have a higher degree of freedom to customize them

To empower business users with the ability to customize fragments added to a page, developers can use editable elements as well as fragment configuration properties. However, sometimes page creators need to make additional changes to the provided fragments, especially when they are large and/or complex.

This feature is solving this, by empowering developers to provide a higher degree of freedom for users to customize fragments where necessary. Thanks to the “fragment compositions” capability, when a page creator adds a composition of fragments to a page, each of the fragments in the composition can be handled independently keeping the freedom to configure, move, delete and add any of them.

LPS-108511 Save a composition of fragments created within the page editor

The page editor allows non-technical users to create and configure rich composition fragments including content, media, interactive elements, letting them create displays exactly the way they want. 

But now users can also save them!

Thanks to that, page creators will be contributing to the effort to offer a consistent experience across sites and pages by being able to re-use multiple times their compositions. The saving fragment option is available to any layout elements.

LPS-98699 Allow Marketers to display a Collection in a Page by controlling how the items of the collection should be displayed

This feature introduces a new way to display collections on pages for users having no coding experience.

Collection Display” is the name of the new fragment that provides an intuitive and user-friendly way for page creators to visually display a collection.  The recommended way to publish lists of content until now was the Asset Publisher widget, which is very flexible but requires more technical knowledge to configure or customize how the list is displayed. With the new “Collection Display” fragment, non-technical users can pick fragments and apply them to the full list of items in the collection automatically. For example, this could be used for fine tuning the display of collections made from pages, blog posts, categories, authors, clients, projects, and so on. For eCommerce projects, a marketer could  visually customize the display of collections by dragging and dropping fragments to the product collection.

Users will be able to get all the advantages of fragments and modern site building and make collections look exactly the way they want!

In addition to that, we also support collections created programmatically called “Collection Providers”. That’s additional flexibility to create specific collections and group assets with more advanced criteria. For example, a developer could create a “collection provider” for the top 5 most purchased products and make this list available for a Marketer to display it the way they want.

Finally, “Content Display” fragments can also be added to a collection. By doing so, assets get linked automatically, giving the possibility to display them with a specific template.

LPS-98582 Facilitate the development of Fragments to display a Collection

The new Collection Display fragment is very flexible, but we want developers building solutions on top of Liferay to have even more flexibility. To that end we have made it possible for developers to create their own custom fragments to display collections, having full flexibility on how it is displayed using HTML, CSS and JavaScript. All while providing a simple and known user experience to non-technical page creators who would just choose a collection in the same way as it’s chosen for Collection Display.

The fragment developer can specify which type of list items are supported by the fragment. The fragment code can know which fields will be available in each content of the collection. It's worth noting that while this is clearly useful in the context of displaying  "Content", these fragments will be capable of displaying any type of information (represented through a Java class), not just content.

LPS-103755 Simplify styling of editables by defining them  with data-* attributes

Fragment developers can include editable elements within the fragments to allow page creators to edit the value and enter text, rich text or images (directly or through a mapping). These editable elements are created with the <lfr-editable> tag which when presenting the final page to an end user is converted into a <div> tag. As fragment and theme developers have started leveraging this feature in more and more advanced ways, we’ve noticed that the <div> tag is not always desirable and it also creates a small inconsistency between the markup in the edit mode and the view mode, that needs to be taken into account by CSS developers.

To solve these challenges, we have introduced a new markup to define editable elements. Fragment developers can now use HTML data attributes as in the following examples for an image and a link editable:

<img src="placeholder.jpg"  alt="Placeholder"
         data-lfr-editable-id="img1"  data-lfr-editable-type="image">
<a  href="#placeholder"  target="_blank"
      data-lfr-editable-id="link1"  data-lfr-editable-type="link">
  Go to placeholder

The <lfr-editable> tags are still available and can even be used in combination with the new way. We plan to keep support for both forever, to ensure existing fragments never break. However we now recommend using data-* attributes to avoid the styling issues derived from the automatically added <div> tag.

LPS-111156 Adjust the page structure tree style

The page structure tree of the page editor now adheres to the styles and colors  by Lexicon and Clay so that it integrates well visually. This change aims to improve the user experience keeping a consistent design to page editor panels.

LPS-109350 Default home page created as a content page

When starting a new site a default home page is created based on a widget template. But as we are moving toward fragments and modern site building we wanted to offer users to start with a home page created with a content page as a default home page. Hence the user will benefit from new features introduced with the fragments capabilities from the early beginning.

LPS-101738 URL redirection management for pages

This new application allows site admins to create redirections from URLs of the site to any valid URL. With this, it will be possible to react really fast to changes in the site without causing users or search engines to not find the content they’re looking for. The new application supports temporary and permanent redirections, as well as setting an expiration date for the redirection to stop taking effect.

LPS-110952 404 URLs list

Complementing the redirection application, we are including a list of URLs that the users tried to access the site and end up in a 404 error. Site admins will be able to create redirections from them, streamlining the process and in the end, helping users to find the content they are looking for.

LPS-98176 Localized history of friendlyURLs for pages

Now Liferay keeps track of all the friendly URLs used for pages for all the languages, automatically redirecting users to the latest URL for the language they are accessing. ()

Platform Improvements

LPS-11068 API explorer

The API explorer is a new web application that allows developers to check the available APIs, their documentation and also perform queries to test their apps during development. It allows to explore all the REST applications and its endpoints. To access, log in the portal and then go to {myportalURL}/o/api.

 It includes a GraphQL client as well, so a developer will be able to define and test their query before including it in the application, accelerating the development.

LPS-109474 Add or update all translations of localized content in a single request

All translations can now be added or updated in the headless APIs using the new set of properties added to localized elements. Every localized property, for example “title”, has an equivalent property that supports multiple values for the translations, “title_i18n”. For scenarios where it is important to maximize the performance, being able to create a content with all the translations in the same request can drastically reduce the number of requests needed.

LPS-103446 Expose actions in GraphQL

In a similar way as we’re doing for the REST APIs, adding the property “actions” to the request will retrieve the queries and mutations the user performing the request is allowed to. With this feature, frontend developers will be able to create apps with dynamic action menus, showing the user only what they can perform, instead of waiting for the server to return permissions errors.

LPS-106981 Improved error management in GraphQL

Now, if the request is trying to retrieve elements that are not available, the server will a 404 error, instead of a 500 http code.


All documentation for Liferay Portal/DXP 7.2 and above can now be found on our new documentation site called  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)


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

  • MySQL 5.7, 8.0

  • MariaDB 10.2

  • 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

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


A special thanks goes out to our Engineering, QA and Release teams who helped make this release a reality.  Also thank you to everyone in our community who spent many hours reporting bugs and providing feedback on new features that made it into this release.


As a long time Liferay developer and community member, I know I have a bias, but I have to say that, after playing with this release for almost two days now, it's really exciting to see the direction Liferay is heading in. The power and control it gives to users who are less technical, or less familiar with Liferay is great, but the fact that Liferay is not doing this at the expense of the developers (by continuing to provide such a rich API) is awesome. Well done once again. Each release of this product continues to keep me excited about what's next. :)

Great, I like this rolling release mode... It is always great to have new functionalities.

We will upgrade from 7.3.1 ga2 to 7.3.2 ga3 in few days.. 


I have only one question : The new release.portal.api property is available for maven projects ? 




Hi..jQuery not works even i checked enabled in system settings/third party. What i'm missing?? 

Is it easy to upgrade from 7.3.0 GA1 to 7.3.2 GA3? I still remember days when starting new version will upgrade everything automatically

Upgrading between 7.3.x versions seems to be working better for me in my testing.  It's faster and I seem to have less issues with it.  You have the option of upgrading on startup again by setting in your properties file.  I would be hesitant to use it in production but it's nice in test/dev.

Hi Jamie,  where can I find documentation for Liferay CE upgrade? My understanding is I don't need do download full new distribution and point it to existing database; instead, upgrade tool will do it for me? liferay-ce-portal-tools-[version].zip (with properly configured property files pointing to existing location) will download even new Tomcat version if needed? I am confused. 

You should run the standalone upgrade tool. Since the rolling releases, there are new features in every GA, and they might require database upgrades. The full portal doesn't do this any more. With regards to code/binary updates: This is up to you. The upgrade routines won't touch your application server, and not even Liferay's code - only the stored data: While Tomcat is provided in a bundle, and newer tomcat versions will be used in later bundles, upgrading and maintaining tomcat is fully on your end. Nothing within Liferay (not even within Liferay DXP) will touch that part of your installation. Naturally, if you unzip an upgraded bundle to a new location, you'll end up with that bundle's  tomcat version.


With Liferay DXP, you'll get a Patching Tool that will take care of binary updates to Liferay components (e.g. jars, and other files living within the web application), but none of that will touch the appserver either. And the Patching Tool doesn't touch the database at all. E.g. you might need to run the upgrade tool on top of the patching tool.

UNCLEAR: why database upgrade tool needs file? Documentation says I need to configure it before running upgrade tool. It must be independent, isn't it, WebLogic vs. Tomcat - database must be the same. Another bug?

I suspect upgrade tool needs access to portal classpath (at least, JDBC driver which is in tomcat-x.y.zz/lib/ext in tomcat bundle) that's why we have to configure and default setting is to pick dependencies from same unpacked bundle; otherwise we need to point explicitly. Thanks.

Hello and thanks for this update :). All works good for us. Have you an idea if the integration of elasticsearch Connector 7 will be release soon ? i tried it with GA3 but still doesn't work :(

I love the new functionality that comes with Liferay but absolutely dread the upgrade. In the past each upgrade has failed and I end up recreating the whole thing from scratch. This time I cannot, and need to perform an upgrade from 7.3.0 to 7.3.2.


There are lots of comments here referencing an upgrade tool and the documentation. Unfortunately none of the referenced links work and also the links are all for the paid DXP version not the CE version. I looked at the upgrade documentation for DXP 7.1 (7.2 is not accessible to CE users)  here:


These instructions are also not clear to me, as a simple user not a full-time Liferay administrator. There seem to be lots of documentation for all sorts of side cases and it looks like a full days reading to understand how to perform an upgrade. 


Can someone maybe direct me to a simple set of instructions to upgrade a vanilla 7.3.0 to 7.3.2 please. My current installation is not Docker, so I am assuming the Docker based upgrade is not for me.


I ran the tool under the /tools directory of the freshly downloaded and extracted 7.3.2 bundle. These instructions never seem to ask for the old installation directory of Liferay 7.3.0 and after successfully running it, it made changes to my DB but what about the files under the old /data/document_library? As  the upgrade tool didn't explicitly ask for my old installation directory and the database itself doesn't know where the actual old installation is, does this mean my documents are no longer there?


I looked everywhere online for a simple set up upgrade instructions and came up empty. No You Tube videos, only references to DXP super tools that are unavailable to the CE community on this website.


Is the CE upgrade tool able to migrate anything else but the DB? Do I have to read pages up DXP documentation to figure out how to move the other data, or is there a utility like db_upgrade that asks: 1) Where is your old Liferay directory, 2) Where is your new Liferay directory, 3) Click upgrade? Surely all the information required is already all there?


Sorry for the rant, love the software, but Liferay upgrades are not my best friend.

The upgrade tool often only upgrades the database (some Liferay version upgrades also moved files around, but often the data folder is ignored). You have to copy it manually and I recommend to do it before you start the upgrade process.


The steps to upgrade are basically:

1) Create a backup/test the upgrade and everything on the backup till everything works

2) Unpack new version

3) Copy data/* from old Liferay to new Liferay/data/

4) Update portal-*.properties according to old files

5) Update server.xml,, ... (Well, basically apply all configuration changes to new Liferay)

6) Start

7) Check logs for errors, if everything is fine, proceed

8) Start Liferay

9) Check if everthing works, files should be there

10) Probably reindex

11) Update your modules and deploy them

12) Check if everthing works as expected

13) Repeat with production





Hi Christoph,


Thank you for these instructions, very helpful. I followed them with the following exceptions and got the upgrade to work:


When copying the data/* directory

a) I copied only the document_library dir because when I copied the elasticsearch dir as well I got exceptions thrown during the process, as well 100's of framework exceptions during liferay startup.

b) I also first deleted the content of the new installations /data/document_library dir.


I had a few issues with portal-*.properties files, I only copied the root file across and also edited the file to change the location of the home dir for the app server.


New install seems to be running fine now, so thank you very much for your help.



All fine.

a) I usually use an external ES server, it's better for performance and management reasons. Only the document_library folder is needed. Note: It is also recommended to disable the indexer for the upgrade.



b) Yes, good.


Personal opinion: Upgrades have become better. I had a lot more troubles with Liferay 6.x -> 6.y than with any 7.x -> 7.y upgrade.


Spoke too soon. Seems like I'm already down the Liferay upgrade rabbit hole and I didn't know it. After the upgrade all my users have simply vanished from the user list. When I try and recreate a user who I know used to exist, I get an error saying the screen name is already taken, so I know there're in there somewhere.


I'm getting errors in the logs like: 

/group/control_panel/manage?p_p_id=com_liferay_roles_admin_web_portlet_RolesAdminPortlet&p_p_lifecycle=0&p_p_state=normal&p_p_state_rcv=1&p_p_auth=jLefuZys is not allowed


Does this mean my old admin user is no longer an admin user in the upgraded system?


If this is the wrong forum to post this for CE questions, please will someone direct me to the correct forum.




Hey Max,


It seems your index is not complete. You should be able to solve this by going to Control Panel > Configuration > Search and do a reindex

Hi Jorge. Thanks, this did the trick for the missing Users.

I have an additional problem. I have images embedded in content pages. The images show up correctly in the page when viewed, but only as a little gray rectangle  when in the editor. The name of the image seems correct, but it doesn't display at all in the editor. Any ideas why?

Thank you for listing these, Christoph. These steps and more information are included in the Upgrade Overview:

Ok, where does it explain that the content of the data folder has to be copied to the new instance?


The section in "Using the Database Upgrade Tool" makes some assumptions that I are almost never true.



cp /old-version/liferay-home/ /new-version/liferay-home/


cd /new-version/liferay-home/tools/portal-tools-db-upgrade-client -j "-Dfile.encoding=UTF-8 -Duser.timezone=GMT -Xmx2048m" -l "output.log"


Apart from the obviously missing "-r" parameter, an average user would here copy the old liferay folder (containing the old binaries and everything) and execute the db upgrade client of the old version. Maybe wondering why he was doing that.


This text obviously assumes that Liferay Home is "elsewhere", and not equal to the unzipped Liferay folder. Nice idea, but I have never ever seen a CE installation where Liferay home is set manually to an external folder.


If this is documented somewhere, fine. But still, nobody does that and so, that upgrade description won't work.


> where does it explain that the content of the data folder has to be copied to the new instance? It says, in the warning in the beginning: "Testing the upgrade process on backup copies is advised." Instead of "copying random data from left to right", I'd personally rather restore a backup on completely unrelated hardware, without any connection to production servers. Then assert that my backup is worth it's money by assuring that it's an exact copy of my production environment.


Only then start upgrade work. Upon any problem: Rinse/Repeat.


It's sooo relaxing to have proof that a backup actually can be used to reliably restore a system

You still need to know what you have to change in your restored backup to upgrade it, so you need to know which steps are necessary and which files are relevant to the upgrade.


The described upgrade steps are simply not correct.


On the one hand: Yes. On the other hand: You hopefully have figured out what to back up (and how to restore) loooooong before you ever attempt an upgrade.



IMHO the steps can be simplified by "restore your backup to a completely new system - just the same way as you've tested before for cases when your main server disappears. Then use this restored system for further upgrade operations."



That's a universal way to phrase the instructions.

Well.  Not really. I have seen several companies, where the backup strategy is: "We take snapshots of the VM ..."

Also, if you backup the whole Liferay folder and the database, it will work too. So. Now what?


Anyway, this is nitpicking. The upgrade guide should be like a cooking recipe and/or a checklist.

Unzip new package.

Copy these folders.

Copy portal-*.properties

Check portal-*.properties and update liferay.home

Check ...

Did you update any files manually? Please check especially

server.xml,, files in osgi/configuration folder, ...

Hint: Unpack the file with the old Liferay version and use a compare tool.

and so on ...


I know what to do because I did it countless times. But for people, who do this the first time, it should be cover as many bases as possible.

Hi Christoph, We're fixing the upgrade steps and making them clearer. Regarding the "-r" parameter you're mentioning for, I'm not familiar with it (it doesn't come up in --help) and will ask about it.


Thank you for your input.



-r for cp (Linux shell copy), not db_upgrade. -r is necessary for directories.

"cp /old-version/liferay-home/ /new-version/liferay-home/"  --> Error


Things like that make it perfectly clear for me that nobody has ever tested these steps because the first line fails always without exception.


I think the upgrade steps should first explain, what each folder* does. If something like that doesn't exist already, it would be really helpful so that people understand what is tomcat, what is configuration, what is data, what is temporary(and can be deleted).

* Some files should be explained too.


Hi Max,

the upgrade process is quite simple in general, most of the other things you mentioned (document library, properties) are just being copied from old Liferay to new "as they are". There might be some problems with 7.3 as it is still unstable and hasn't been officially released yet, but usually, it's quite straightforward. You could write a post on Liferay forums if you have some issues, I think it's a better place to get help than here.

Hey Max Max Max,


I'm sorry to hear that you have had so many problems upgrading between rolling releases. Our promise is that those upgrades should be very easy in a wide majority of cases (the only exceptions could be when there are heavy customization or db inconsistencies).


In order to improve, I'd like to know more about your problems to find out if the root cause is in lack or inaccurate documentation or actual problems in the automated upgrade processes.


Did the steps mentioned by Christoph help? Are you able to successfully upgrade following them or do you find still run into problems?

Hi Jorge,


I can't remember the details of my past upgrade problems but I often remember db errors appearing everywhere. The main problem with this upgrade was to find the set of instructions that Christoph was so kind as to type up.


If these instructions are elsewhere in the Liferay documentation, then it would be good to link tho this in the release notes or in this announcement for us plebs.



Hi Max, Updating from one 7.3 Liferay Portal CE GA to another GA is demonstrated in the following article: Updating Liferay Portal CE -  

I'm sorry you didn't find it. We're going to add the article to the upgrade section so that it can be found there too. My apologies. Note, if you do need to upgrade from an earlier version (e.g., from 7.2 Liferay Portal CE) you can run the upgrade using a Docker image. That is, you can continue using an on-premises installation but simply use a Docker image to upgrade your database. The CE Docker images are mentioned in the second paragraph in the article Upgrading Via Docker -


I hope that makes your upgrade a quick success!



Hi Jim,


Thanks for pointing me to the upgrade page. The upgrade instructions on that page are very different to the instructions given by other to me here. There are also ambiguities if you can please clear up for me before I attempt this upgrade again.


- There is no mention of any copying of the data directory across. 

- There is no mention of using the script. Using this script sounds MUCH easier than a) learning how to use the gogo shell and b) going through 5 different gogo steps for each module.

- Step 5: Clean up DXP cache. - I assume this is on the new installation?

- Step 6: Start the application server again. - According to the instructions I have not started the new server yet, so do I start the old server 'again'. Why?

- I assume again I run the gogo shell here against the new server and no the old.


@Jorge: I am certainly not looking forward to going through all this every time I upgrade . This is exactly what scares me about every Liferay upgrade I have to do. I just read a post that there is some error in the 7.3.2 upgrade script where some db column is not properly upgraded and users cannot be deleted anymore. Any small DB error seems to propagate through the upgrades and after two upgrades the DB breaks and I end up having to throw it away and start from scratch. My above mentioned upgrade attempt that resulted in my users disappearing and permissions broken leaves me with the permanent niggle in my back of my mind that my DB is corrupted and there are other things that will just break down the line and I will sit for days on forums trying to figure out what. That is why I often just cave in an install from scratch and manually copy stuff over because that crazily feels easier to me than the potential future issues. But that is not a real solution long term.

Where does it explain that the document_library folder has to be copied?

Hi Christoph, We're still in the process of fixing and improving the documentation for upgrading a Portal CE rolling release. You can follow progress at


The steps include copying the data folder, which includes the document library if that's where you have configured you've configured your File Store to be there.

Christoph, Max,

The upgrade documentation has been improved based on your questions and suggestions. Here's a summary of the changes:  

Upgrade Overview - The overview is always the best place to start when considering an upgrade for DXP or CE. It explains what areas to consider and which database upgrade approach(es) to consider. The articles that follow center on database upgrade, but list steps for all parts of the upgrade (including migrating data/ folder contents and configuration files) and link to detail articles where needed. Backing up your existing installation and using a backup installation/db copy is essential--we warn about this in the overview and articles on upgrading using Docker and the Database Upgrade Tool.

Upgrading Via Docker - Is for non-critical CE upgrades, especially upgrading from one rolling release to another (e.g., 7.3.0 - 7.3.x). Note, your new installation need not be a Docker image, you're just using the Docker image to upgrade your database.

Using the Database Upgrade Tool - Is for any Liferay edition (DXP or CE), but is a must for DXP, critical servers, and clustered environments. It allows you to dive deeper into database upgrades, when things don't work in one shot (e.g., Upgrading via Docker).

I hope you find the improvements helpful and easy to follow. We're open to more suggestions. And thank you for your patience.