Liferay 7 Alpha 3

Here we are again, following our bi-weekly releases plan with our third alpha release. We are still working hard to reach beta status as soon as possible and I would like to use this opportunity to explain what our criteria is and how our focus on high quality is driving this release more than ever.

But before that, let me brag a bit about our hard work during these past two weeks: this release fixes 167 bugs resolved since Alpha 2 and adds 58 improvements.

Last week we had an opportunity to showcase the release at our North American Symposium in Chicago. If you couldn’t attend (or even if you could), keep an eye on the site since the slides will be published soon. Coming next we have events in Viena, Austria and Sao Paulo, Brazil (another great opportunity to meet many Liferay developers).

Highlighted improvements

First I would like to highlight how Lexicon keeps evolving and all of the portlets that already use it get a better User Experience thanks to that. We are also applying lexicon-based designs to more and more out of the box applications. Specially those accessible from the product menu (that includes personal applications, site admin applications and control panel applications).

One portlet that fully finished its redesign is Site Teams. One view that I particularly like is the list of users within a team. It’s so nice that it’s worth showing a picture here:

Pretty neat, right? This is really how it looks, no photoshop at all.

The following applications were also fully finished:

  • Page Templates

  • Site Templates

  • Tags

  • Categories

Additionally some important applications debuted their new lexicon based design. The most relevant of them is Documents & Media and while it still has further work to do, it’s already looking and feeling so much better.

A new application also debuted in this release. It’s called System Settings and allows a super administrator to change the configuration at a system level from the Control Panel. System level configuration is the one that affects all portal instances and sites. The portlet offers many forms organized in 5 categories (subject to change) and is fully extensible. Any module deployed to Liferay 7 can use Liferay’s new Configuration API or OSGi’s Configuration Admin API to define their configuration and have an automatically generated form for free:


Alloy Editor, one of the most acclaimed products presented at our different events, has expanded its usage to several portlets.

In wiki Alloy Editor is used out of the box for both HTML and Creole formats. For Creole, check out the full page view and how you can use it to write Creole on one side and have a live preview next to it.


Pretty cool, right?

It has also been applied to the HTML fields of Web Content, Documents (metadata) and Dynamic Data Lists. For all of them Alloy Editor allows providing rich fields within the form without disrupting the desired flow for filling the form.

This is just the beginning though, we still need to do some look & feel tweaking to make sure Alloy Editor is perfectly integrated.


Finally, and I kept the best for last, the new Forms application has had many important improvements. Probably the most important is the ability to define a workflow for a form. 

To make this capability even more powerful we have also made the default Workflow Engine, Kaleo, much more modular. Now the Action Executors are OSGi modules so it’s fairly easy to add custom ones to create any type of workflow you may need. This can be useful to integrate the with an external database or service.

Some other additional improvements of the Forms application are:

  1. Ability to view details for an specific form entry

  2. Added support for adding captcha challenges to forms

  3. Ability to configure a redirect URL after submission

  4. Ability to export the answers of a form to CVS and XML


That’s about it in terms of highlights. Check the full list of 58 improvements to find out more or just browse around since there are other “partially done” improvements that you won’t see in that list.

Release criteria for Alpha, Beta and Release Candidates

As promised at the beginning I wanted to cover a bit more than Alpha 3 this time around and explain our release criteria. Release criteria is the set of rules that we use to evaluate a release and determine whether we should flag it as Alpha, Beta or Release Candidate. For Liferay 7 we are raising the bar since a big goal for us this year is to have very high quality for 7.0 from the very first GA release.

In order to release Alphas, the criteria is:

  1. All major features finished

  2. 60% pass rate for our automated priority 5 functional tests

  3. Bundle with Tomcat available

This Alpha release met these three requirements (as did the previous two) and already met quite a few from the Beta criteria which are as follows:

  1. Data upgrade finalized for all bundled applications: it’s almost ready but we missed a few fixes for web content and wanted to do some further testing with real world dbs to give you the go ahead to test it on your own.

  2. Bundled plugins/modules included: our final bundles come with many plugins/modules included out of the box. For beta, we want them all to be included (in previous releases we skipped a few that were not fully ready)

  3. Bundle with Tomcat and Wildfly available

  4. Official languages translated to at least 70% of all keys

  5. Releasability index: at least 75%. This is a metric that we came up with using a formula that takes into account all the known and verified bugs reported in JIRA (remember that your bug reports for alphas and betas help a lot) as well as pass rates for our functional automated tests.

We will keep making improvements to reach Beta status as soon as possible, but until then we will keep calling them Alpha

The next step after reaching Beta status is to get to Release Candidate (RC) status. As the name implies an RC release is considered to be a candidate to become a final release. Here is the key criteria that a release needs to meet as it is being built to be flagged as RC:

  1. All Beta requirements are met

  2. Releasability index: 100% (with 100% P5 tests pass rate and 0 Fix Priority 5 bugs fixed)

  3. Environment tests running for all supported app servers and databases

  4. End to end testing (including Marketplace installations and licensing)

  5. Official languages translated to at least 99%

  6. Lexicon based designed applied to all apps accessible through the product menu

Once an RC is out the door the final call will be made based on the internal and external testing performed after it comes out. If important issues are found after the release, they will be fixed and a new RC will be built until one is honored with the GA flag. Ready to be used in production :)

Ready to try it out?

I hope all this info gave you enough incentives to download it. If so go ahead and get Liferay 7 Alpha 3 now from Sourceforge, and let us know what you think.

Update Dec 1st: replaced the image showcasing Lexicon based improvements since the original one was of a view that didn't make it into Alpha 3.

Hi Jorge,

this looks very nice and I love Lexicon.
In this example "Site Membership" I have one more feature request.
Would it not be great, if you see the role of each user that he owns in this Site?
So you can see immediately what a role a user has for, this info would still fit very well under the Screen Name for example.

Best regards,
Hey Lukas,
Thanks for the feedback. That info is shown in the "table" view. Take a look at the upper right corner, under the search box. Those three icons allow switching among Icon, list and table view. The one in the screenshot is icon view and puts an emphasis on the user picture and tries to limit additional information to avoid adding noise. In any case I'll forward the suggestion to Ivan, the designer of the app so that he can think about it.
Hey Jorge,
thank you very much for your quick reply and your informations.
I understand the problem, but in my opinion I think it is also very important to see this information - but this is just my personal opinion.
Thank you to forward the request.

Wish you a nice weekend.
Hey Lukas,

I have good news. What you were asking for is already implemented, however it is not showing the role info when the only role is Site Member and that's the case for all users in my screenshot above. We are going to change that so that the site role is also shown in that case. We are also discussing the removing the screen name from the card to reduce the information noise.
Hi Jorge,

thank you very much for your reply.
That sounds good!
I think that's a good idea, in my opinion, this information is much more important than the screen name.

Do you remember the following entries?

Have you some information if this has already been implemented or still is in developing?
I have not found any settings in this regard since Milestone 4, but maybe I was not thorough enough.

Thank you!
Hey Lukas,

We will include those features as part of this story during the upcoming weeks

You can "watch" the story to see the progress there emoticon
Um, I have Alpha 3 running and Site Memberships portlet doesn't look anything like that, and I don't see anywhere in the Configuration to make it look that way. If I'm missing something obvious please let me know.
Also, is there a reason you are no longer using FCKEditor ? I ask because all the content providers that use Liferay have become used to the good, bad, and the ugly of FCKEditor, and what Liferay has done by replacing it is tossing out those years of experience. And for what? Other than closing tag completion, what does Alloy Editor do that's fundamentally better, and would warrant such a major change in the user experience? Because honestly, I've tried using Alloy Editor and there's minimalism, and then there's not providing enough clues to make the tool usable. I'm afraid Alloy Editor falls into the latter category. Not to mention that in trying to write some basic web content with it I noticed that it was eating my HTML. That is, I put a jumbotron div in with an h1 inside, saved, it displayed fine, went to edit it again and the enclosing div with the jumbotron class was missing. Alloy Editor really seems to me to be innovation for the sake of innovation without actually solving a problem or providing a better user experience.
And now that I've attempted to dampen your enthusiasm, I have one suggestion: I wish the site logo would allow SVG files. Obviously portal-normal.vm can be hacked to insert an SVG logo, but it would be nice if site owners could do this without breaking the site logo management functionality.
Hey Joseph,

Thanks for your feedback. Let me answer point by point:
1) Site Memberships: I was surprised by your statement so I downloaded Alpha 3 from sourceforge (vs building it from source) and tried it out... and you are right! Thanks for letting me know. I'm going find out what's happened with that build and if it cannot be fixed will remove that part from the blog entry.
2) First of all, note that it is still possible to revert back to using CKEditor if that's what you prefer for your Liferay installation. We think though that the approach of Alloy Editor provides a better user experience and solves many UX issues that we have identified over the years. As you mention authors used to the old ways may have a hard time adapting to changes, and that's why we take seriously keeping the old way of doing things as an option whenever it is possible. But at the same time we should not allow that argument to prevent improvement.
3) Regarding SVG files for logos I think that it's a great idea. Can you create a feature request for it and promote it?
Hey Joseph,

Regarding #1, I found out that the commits that applied the look and feel of the original image didn't make it into the release. I have changed the screenshot to one that is very similar and did make it into the release. Thanks again for noticing this.
1) Well, it's nice to know what Site Memberships will look like. 2) Glad to hear we can fall back to the familiar but clunky looking CKEditor. I went and looked at the Alloy Editor website and saw what the project is trying to do. I'd say it's a hard job, because the user is still faced with the gulf of what a WYSIWYG editor can provide versus what can be done by knowing the CSS and working in the HTML source. So while I applaud the effort, I'm not sure how big the payoff will be. I would be happy to be wrong on that, though. Actually, that raises an interesting question: what do your content authors do? That is, if we look at the front page of, what tools were used to build that web content, and was most or even any of it written in CKEditor? 3) OK, I'll do that. Thanks for the link.
[...] Apache Karaf - Version 4.0.3 Beta: WAS Liberty beta with tools (December 2015) Plants by WebSphere example application Arquillian Liferay 1.0.0.Alpha2 Released HTTP/2 With JBoss EAP 7 - Tech... [...] Read More
[...] For what it is worth, take a look at - this is the screenshot... [...] Read More