Liferay Portal 7.3 CE GA2 Release

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

Jamie Sammons
Jamie Sammons
5 Minute Read

Liferay Portal 7.3 CE GA2 is our second release using our new Rolling Release cycle. For more information on our new release cycle please find the announcement here.

Docker

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.1-ga2

Download

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.

Improved Dependency Management

Beginning with Liferay Portal 7.3 CE GA2 it’s now easier than ever before to manage dependencies within projects.  Instead of declaring a dependency for each api, all dependencies can now be defined with a single declaration. When using an IDE such as Eclipse or IntelliJ all apis are immediately available in autocomplete for immediate use.

To get started, update the projects build.gradle file from:

To contain the following dependency:

compileOnly group: "com.liferay.portal", name: "release.portal.api", version: "7.3.1-ga2-3"

For example the build.grade file from above we become:

New Features

Liferay Portal CE 7.3 GA2 includes several new features mainly in Experience Management and some in Platform improvements. 

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.

Nesting layouts and more flexible layouts - The non technical users can now nest a layout into another one, and thus creating sophisticated page layouts using drag and drop. In GA1 the user could create horizontal layouts with multiple columns. But now it is possible to combine, split, nest, duplicate the layouts and thus unleashing the users’ creativity.

More info: LPS-102328

 

Workflows for Content Pages - Users can now define a workflow process for approval of creation and changes for content pages.  Just like for Web Content articles and other content types, administrators can specify a different workflow process at different levels: virtual instance level, site level and all the other entities (see workflow documentation). Once the workflow is enabled for the Content Pages, every new Content Page will go through the approval process before publication. Thus, the content reviewer can preview a page with pending status and approve, reject or request additional changes.

More info: LPS-103815

Support configuring permissions for Widgets in fragment-based pages - This feature allows users to configure permissions for widgets added to fragment-based pages (including: content pages, master pages, page templates and display pages). This will allow users to control which visitors can view the widget, so that some visitors may see it while for others it's fully hidden. It may also be used to configure other permissions such as allowing certain logged in visitors to configure the widget.

We’ve taken page templates and master pages into account as well. If you create a page based on a page template, all the widget permissions are copied to the page. The permissions in widgets from the master pages are set in the master page, so you cannot change them in the page itself.

More info: LPS-102583

One of our goals with the Rolling Releases is to respond faster to feedback so we want to mention some of the feature requested that we have implemented in this release.  Feature requests are new features our community members and customers would like to see added to our products, and also an opportunity to have your voice heard by using the voting system to support ideas that you would like to see implemented. The following feature requests were implemented in GA2:

Developers and Sysadmins

  • Allowing to enter longer values (255) for category names
  • Adding remote public Layout fetchLayout method
  • Ability to have autocomplete in the fragment editor for variables, taglibs and resources.

Page Designers / Administrators:

  • Visual identification of empty portlet-columns in Widget pages
  • More flexible configuration of the number of items display with RSS Publisher
  • Ability to hide/show portlet controls on the Widget pages
  • Ability to define navigation menus in Global to share them across all sites
  • Ability to store custom information relevant to my sites on the items of a navigation menu

Introducing Asset Libraries - with this new feature, it is possible to create dedicated libraries for content that make sense together and have better-isolated control on them. Asset libraries make it easier to reuse resources across different sites, connecting them only to the sites where you need to provide access. 

Asset Libraries support the storage of documents and web content allowing a marketing team to organize collateral used in a campaign in an asset library and connecting it to the sites where the campaign will be run.  While creating a page, or writing a blog post, content authors can access the connected asset libraries and use images or content uploaded. 

This feature is experimental, which means that before the launch of the Liferay DXP 7.3 GA1 some features may change, from the way to interact with the libraries, to the types of content that can be stored and reused. Additionally, you may find some differences in behavior that may affect existing applications. If you don’t want the new behavior, or are not interested in Asset Libraries, you can disable the feature in Control Panel -> Configuration -> System settings -> Asset Libraries.  More info on (LPS-102412, LPS-102471, LPS-102496)

Platform Improvements

Support for batch operations in the headless APIs: Now the headless APIs support batch operations allowing to perform requests over multiple elements in a single request asynchronously. (LPS-98648)

Retrieve all translations of localized content in a single request in the headless APIs thanks to the new custom header “X-Accept-All-Languages” (set to true). For the scenarios where it is important to retrieve all the translations of content in order to maximize the number of requests, we have introduced a new set of properties that include this information. (LPS-106757)

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

Kudos

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.

Page Comments
thumbnail
Dominik Marks
5 Years Ago - Edited

What can we expect from the rolling release feature in terms of upgrade processes? To update from 7.3.0 GA1 to 7.3.1 GA2 do we still have to shut down 7.3.0, run the upgrade tool and start up 7.3.1? 

 

Or can we just shut down 7.3.0 and start up 7.3.1 immediately and everything is done? If not, is that a planned feature?

 

Please sign in to reply.
thumbnail
Krzysztof Gołębiowski Dominik Marks
5 Years Ago - Edited

We have a new experimental environment in our company, that initially was built on the last GA release of 7.2, then migrated to 7.3 GA1. A few days ago I tried to migrate it to 7.3 GA2 using the standard upgrade-tool and even though it was mostly successful (there were some issues with messageboards that we don't use at all) the final portal was broken. There were many weird exceptions in logs during runtime, and entire Web Content together with all the articles was gone.

I didn't want to lose my time on fixing upgrade issues and as there is not much functionality on that site, I just scrapped the old instance and installed everything on fresh Liferay GA3. Be careful when doing your upgrade :)

Please sign in to reply.
thumbnail
Jorge Ferrer Dominik Marks
5 Years Ago

You can achieve that by setting the following portal property to true:

 

# # Set this to true to execute the upgrade process when the portal starts and # modules are activated. # # Env: LIFERAY_UPGRADE_PERIOD_DATABASE_PERIOD_AUTO_PERIOD_RUN # upgrade.database.auto.run=false

 

This actually used to be true by default, but in many production environment that turned out to be undesirable because more control is desired over changes to the database model, which is why we now recommend using the upgrade tool. But if this is valid for your case, it's a simpler process.

Please sign in to reply.
Mike Bigelow Jorge Ferrer
5 Years Ago - Edited

Hi,

 

I'm installing  7.3.1 GA2 atm, and curious about the upgrade process when 7.3.2 is released.

 

1. Is this setting all this is required to upgrade both the files and DB?

upgrade.database.auto.run= false

2. Is it set in the portal-ext.properties file followed by a shutdown/startup?

3. Any other requirements to upgrade in the future 7.3.1 to 7.3.2?

Please sign in to reply.
thumbnail
James Hinkey Mike Bigelow
5 Years Ago

Hi Mike, 1. It only upgrades the DB. It's best to check the Upgrade Overview (linked below) to determine what else might need upgrading in your DXP installation. 2. It's recommended to use the -e LIFERAY_UPGRADE_PERIOD_DATABASE_PERIOD_AUTO_PERIOD_RUN=true argument for the auto run over using a portal property, because it's easy to forget to disable  the property once you've set it. :-) ... running the database upgrade again by mistake may cause issues. 3. I'm not sure whether there will be new upgrade requirements for 7.3.2. We're not expecting any at this time.

Please sign in to reply.
Mike Bigelow James Hinkey
5 Years Ago - Edited

To confirm only these steps below in the link are required to upgrade later on? (unless a new upgrade requirement is listed).

And these steps "Upgrading Via Docker" will perform all files & DB?

https://learn.liferay.com/dxp-7.x/installation-and-upgrades/upgrading-liferay-dxp/upgrade-basics/upgrading-via-docker.html

Please sign in to reply.
thumbnail
Alberto Chaparro Terleira Mike Bigelow
5 Years Ago

Hi Mike, If you mean document library files when you says "files", yes, the upgrade takes care of it (although there are no modifications in this matter during the upgrade between 7.3 GAs. If you mean Liferay jar files, then, if you use the latest docker image to upgrade, yes, the updated jars for latest GA will be available. I hope it helps.

 

Cheers!

Please sign in to reply.
thumbnail
Christoph Rabel
5 Years Ago - Edited

I tried the new version a bit:

 

1) Master pages

I'd like to know a bit about the plans here.

Is it (or will it be) possible to specify multiple dropzone areas? That way I could allow different elements per drop zone (e.g. header, content, footer).

 

Another nice feature would be to have permissions for dropzones. Some editors could be allowed to configure the whole page, others only some parts of the page. Maybe even get rid of the need to create a theme altogether. The header, including navigation, login, whatever, could become one or more widgets and only the top level editor can change them. Others are restricted to content.

 

Btw.:

My question here is also  a bit driven by the dashboard usecase. In the last couple months I had discussions with 4 different, unrelated customers who want a dashboard for end users. All with different usecases and specific needs but the requirement that endusers can configure their dashboard page, add/remove widgets.

 

Maybe the dashboard usecase can/should be addressed in a different way, but I just thought about it.

 

2) Asset Libraries

GREAT feature. Love it. For most customers, we have sites that are just "storage".

 

A very nice feature would be to be able to set default permissions. Liferay permissions are complicated; great, powerful, but complicated.

 

We have resolved that by using extra sites per "group". e.g. a marketeer site with marketing only documents. Only site members see the content, can create content there  and so on. The nice thing is: A news created there is automatically only visible to marketeers. So, they can't err with the permissions.

 

So, I would like to be able to define default permissions for all assets in Asset Libraries.

 

3) Ability to define navigation menus in Global to share them across all sites

 

I tried it and I found it very limited (at least so far). The problem I see:

Let's say, I create a footer menu. To add the links to that global menu, I have to copy the links and the names (not to forget possible translations) and add them one by one to that global menu. Uh. Then, whenever a linked page is renamed/url changes/deleted, I have to update the global menu too. Of course, I will never forget to do that ...

 

I probably will ignore that feature. We currently merge the whole navigation of sites into the parent site (e.g. in the Department menu, the editor adds a page "Department X" and we automatically insert the navigation tree from the Department X site there). And in Department X we show the navigation from the parent.

 

Swell would be the option to create navigation menus AND then use them as "pages" in other sites. With that I could create navigation menus where e.g. each tab contains the navigation menu of the subsite.

 

 

 

Please sign in to reply.
thumbnail
Jorge Ferrer Christoph Rabel
5 Years Ago

Hey Christoph,

Thanks so much for trying out the new version and providing such detailed feedback. 

 

> 1) Master pages

 

 

We have several features in mind for the next phase of master pages, but we wanted to analyze the initial usage and feedback to decide on priorities.

 

> Is it (or will it be) possible to specify multiple dropzone areas? That way I could allow different elements per drop zone (e.g. header, content, footer).

 

Yes, that's something we even debated to provide during the first phase. But it adds complexity (and requires some changes in how dragging in the page editor works) so we decided to wait and ensure that it's necessary. Could you create a Feature Request for it?

 

> Another nice feature would be to have permissions for dropzones. Some editors could be allowed to configure the whole page, others only some parts of the page.

 

This is something that needs to be thought through. We know from experience how overdoing permissions leads to a lot of flexibility that few people use due to how hard it is to get it right. What would be super-useful is if you could create a feature request describing the need (not the solution) and add real-world specific examples of the different types of users and the desired permissions for each. This type of information helps us find the simplest solution possible to solve the need.

 

> Maybe even get rid of the need to create a theme altogether. The header, including navigation, login, whatever, could become one or more widgets and only the top level editor can change them. Others are restricted to content.

 

We do have plans to leverage master pages, fragments and a new feature coming next called the style editor to reduce a lot the need to create full blown themes (the current ones). Looking forward for your feedback once we roll it out (probably by GA4 or so)

 

 

> My question here is also  a bit driven by the dashboard usecase. In the last couple months I had discussions with 4 different, unrelated customers who want a dashboard for end users. All with different usecases and specific needs but the requirement that endusers can configure their dashboard page, add/remove widgets.

> Maybe the dashboard usecase can/should be addressed in a different way, but I just thought about it.

 

Yeah, dashboards might require a different way of building a page. It's something that we are not prioritizing right now, but it would be very interesting to hear more from you about the use cases you are finding. 

 

> 2) Asset Libraries

> GREAT feature. Love it. For most customers, we have sites that are just "storage".

 

Awesome, thanks for the feedback. I've forwarded it to the product managers and team lead in charge for this.

 

> 3) Ability to define navigation menus in Global to share them across all sites

 

> I tried it and I found it very limited (at least so far). The problem I see:

> Let's say, I create a footer menu. To add the links to that global menu, I have to copy the links and the names (not to forget possible translations) and add them one by one to that global menu. Uh. > Then, whenever a linked page is renamed/url changes/deleted, I have to update the global menu too. Of course, I will never forget to do that ...

 

Understood. One idea would be to allow adding a Menu Item of type page to the global navigation menus and let the user select a site first and then the page. We would need to think through which sites to show for selection, but otherwise it wouldn't be too hard to implement.

Would this make global menus useful for your use cases?

 

> Swell would be the option to create navigation menus AND then use them as "pages" in other sites. > With that I could create navigation menus where e.g. each tab contains the navigation menu of the subsite.

 

You mean to support composition of menus from other menus, right? 

This could be done by adding a new type of Menu Item which is a link to another menu. We would need to think through the permissions aspects of which other menus would be selectable (if they are from other sites), but otherwise I think it's doable. Please go ahead and create a feature request for this as well.

 

Thanks Christoph!

 

Please sign in to reply.
thumbnail
Christoph Rabel Jorge Ferrer
5 Years Ago - Edited

Hi Jorge,

 

I have created two feature requests:

https://issues.liferay.com/browse/LPS-111889

https://issues.liferay.com/browse/LPS-111891

 

I understand the problem with the dropzones and also the reluctance about permissions.

 

After writing the feature requests, I mulled it a bit and I mostly had a "Theme 2.0" in mind. (I wrote  a bit about the issues I have with the current themes here: https://liferay.dev/forums/-/message_boards/message/114387658 )

 

My main idea was, instead of creating a theme, I create the master page, add a header area, with logo, navigation, ...; a content area and a footer area (with sitemap, social links , ...). This master page will be my new "theme".

 

It is quite possible that implementing the above features simply makes my feature requests obsolete.

 

---

The main dashboard usecase:

One of our potential customers provides multiple services and his clients have subscribed to a number of them. The services differ per end client.

 

Each client should have a freely configurable dashboard with the widgets they have subscribed too. Which widgets can be used by the client is defined by an account manager.

 

On top of that, those account managers should be able to "preconfigure" these widgets for the clients. The clients should not be able to configure them, only to add/order/remove them.

 

I think, this is the most complicated of the possible usecases we have. But all have in common that end users should be able to add widgets to their pages. They should not be allowed to do a lot of configuration (maybe minor things like changing colors).

 

Furter usecases:

- Undo

- Reset

 

---

Menus:

- Selecting pages from other sites

 

Yes, that would be helpful. It would increase consistency. Deleting a page would not lead to a broken link in that menu.

 

I still think that a general composition feature would be the most useful thing. I have added a feature request (maybe it is a bit to "solution" oriented, but I hope the idea is clear)

https://issues.liferay.com/browse/LPS-111895

 

Note: I am not sure, if it is better to link to a page (in the default navigation) in another site or to a navigation menu. Both have their merits.

 

Btw.: Yes, the permission thing is tricky. So far we could "get away" with implementing only two usescases:

 

a) The admin sets the same permissions on "linking page" and the site.

That way, we could avoid checking the site permissions, we just looked at the page.

 

b) The admin specified the parent site and we simply list the viewable subsites in the menu.

Here we never look into the sites, we just link to the sites default url. We use that for "dynamic site lists" like working groups where the user can be member.

 

The customers could so far live very well with some restrictions. To have only one main menu for all sites was worth it.

 

Best wishes, Christoph

 

Please sign in to reply.
thumbnail
Jorge Ferrer Christoph Rabel
5 Years Ago

Hey Christoph,

 

Thanks for your reply and for creating the feature requests. I've replied in each of them.

 

Regarding the Dashboard, my first impression is that your needs are a bit specific and I can't identify features generic enough that we could add to the roadmap yet.

 

Regarding themes, the ideas that we have for lite themes as a combination of styles+fragments+templates should solve many of the pain points you mention in your post. They will be easier to build, deploy/import and maintain :)

 

Jorge

Please sign in to reply.
thumbnail
Christoph Rabel Jorge Ferrer
5 Years Ago - Edited

Hi,

 

Themes: I think so too. Once I can define a header and a footer, I am pretty much golden. There are some missing pieces, e.g. fonts, or how to change the technical head of a page, but I can see already that I can get pretty far without ever creating a theme.

 

Dashboard: I have described the most complicated dashboard usecase we had so far. I am not sure, what you can do here, I just wanted to mention it, since the topic came up quite often in the last couple of months.

 

I have not tested it,  but I think, the most common usecases could already be implemented using master pages.

 

I can create simple widgets (with no or very simple configuration options) and create a master page allowing only those suitable widgets. This should work pretty well.

 

Permissions could be tricky, I probably need to remove either the owner permissions on the dashboard pages or give them a different owner or something like that.

 

Where I have a difficult time is the usability. While it is well suited for editors, it isn't so nice for untrained users, sometimes even without IT experience. They need to go to edit mode, use the menus on the side, publish, ...

 

I believe, in a "dashboard mode", edit mode has to be handled differently and without publishing. One dashboard I know has a large "+" card at the bottom, clicking it allows me to select a widget type. New widgets are always added to the end. I can always freely drag & drop them around.

 

Something like that would be nice for dashboards.

Please sign in to reply.
thumbnail
Christoph Rabel Christoph Rabel
5 Years Ago - Edited

I just noticed that I can't edit headings on a master page.

 

I have added a row above the dropzone. Then I added a Heading. But I could not change the text. Interestingly, it let me add a link to the heading and specify a color for the font.

 

When I created a page from that master page, the link was gone, the color worked.

 

I tried it with a button and an image too, seems to work there. I could edit the button text and select an image.

 

Please sign in to reply.
thumbnail
Jorge Ferrer Christoph Rabel
5 Years Ago

That's not the expected behavior. You should be able to edit the heading and any other editable and fragment just like in a regular page. Also, everything set up should be preserved when creating a page out of the master page.

If you can reproduce the behavior consistently, please file a bug in JIRA. Please check if there are any Js errors in the console and include them in the ticket if that's the case.

Thanks!

Please sign in to reply.
thumbnail
Christoph Rabel Jorge Ferrer
5 Years Ago - Edited

I tried it again, I can consistently reproduce the issue. BUT I have also downloaded master now and I can't reproduce anything of it there. I guess, whatever the problem is, it is already fixed.

Please sign in to reply.
Lee Jordan
5 Years Ago - Edited

It's getting better, the WEM is still not feature complete. We've got to have 100% features ported from widget pages for widgets in content pages. The trouble is whatever we upgrade to (and clearly Liferay as a platform is in a state of flux and not stable ), the trouble really is we will be stuck with whatever version we land on for 4 years.

 

It's not good to have both widget pages and content pages, we need a full move to content pages eventually, or renaming the things to be "Classic Pages" and "Modern Pages". The terminology is still too obscure for most users and most users will want to use web content on content pages because of the wording alone.

 

Look and feel menu currently is the biggest thing missing from widgets (portlets) on content pages, and there are no portlet toppers when not in edit mode. You can't "edit web content" in edit mode and the plus menu that allows fast access to add a new template to a web content has yet to find its way to Content Pages.

 

Please provide a timeline and a target version of Liferay that will have this massive change to Web Experience Management feature complete. Overall in 7.3 it's 80% there, the next 20% will be hard but it must be done. We must make this change over to content pages with backwards compatibility, we can't continue to split use cases between two types of pages.

 

The changes were announced a long time ago, this has been a long journey and a worthwhile one, but please let's not stop at 80% done, let's push through and get to 100%.

Please sign in to reply.

Related Assets...

No Results Found

More Blog Entries...

Ben Turner
October 21, 2025
Michael Wall
October 14, 2025
YOGESH CHANDRA
October 08, 2025