Liferay 7 Alpha 2 - Getting closer to beta

Company Blogs 2 novembre 2015 Da Jorge Ferrer Staff


We continue our path towards releasing Liferay 7 with a new alpha release that focuses on fixing bugs and small improvements. This release fixes 254 bugs since Alpha 1 and adds +100 small improvements.

During this time we have also had the opportunity to present Liferay 7 twice: first in Germany during DevCon and later in Spain during the Spain Symposium. We are super grateful with the very positive feedback of this new version, its features and the significant architectural improvements to make Liferay (and your developments) much more modular. If you didn’t have a chance to attend any of these two events, don’t worry because you will have more opportunities. Coming next we have events in London (later this week), Florence, Italy (next week), Chicago (can’t miss this one if you live in the US!), Viena, Austria and Sao Paulo, Brazil (another great opportunity to meet many Liferay developers).

During these events and through the Community Expedition (you are already enrolled, right?) we are receiving tons of feedback and we are working hard to satisfy as much of it as we can. Here are some key aspects that we are focusing on, highlighting what you can already see in this Alpha release:

  1. Product Menu: We’ve received a lot of good feedback on the new product menu but we have also realized that it can be a bit confusing, especially at first. We have been playing around with several variations and testing them internally. In Alpha 2 you can see some small improvements based on the conclusions from these tests, such as moving the control bar to the top.
    More improvements will come in upcoming releases.

  2. More application redesigns based on Lexicon: We keep working on new designs for the out of the box applications. In this release Dynamic Data Lists, Structures, Templates and the new Image Selector debut a new Lexicon based design.

    We are currently working on the rest of the portlets in site administration as well as the user administration portlets.

  3. Data upgrades: Alpha 2 includes a new upgrade framework that we have created to provide more control over the upgrade process and increase reliability. Most of our portlets have already been updated to use the new framework so if you consider yourself brave enough you can go ahead and try to upgrade your existing site(s). If you do, please give us your feedback. One of the great benefits of this new framework is that it will be possible to execute the upgrade for each module independently, check the status, re-run it as many times as desired, etc. This will be especially useful in portals with tons of data.


Ready to download it? Get Liferay 7 Alpha 2 now from sourceforge, and let us know what you think.


Liferay 7 Alpha 1 - the beginning of a brand new user experience

Company Blogs 30 settembre 2015 Da Jorge Ferrer Staff

As announced in my last blog post, the period of our milestones has finished and we are getting into the launch field with the release of Liferay 7 alpha 1. We appreciate all the feedback from the people downloading the milestones and participating in the Community Expedition program. If you haven’t sent your feedback yet, it’s never too late to make Liferay the best fit possible for your needs :)

Most of our cross-functional teams have been focused lately on trimming down the known bugs, since delivering a high quality release is our #1 goal for Liferay 7. But don’t think for a second that this alpha 1 is going to be boring to test. On the contrary, since it is the first release where the Lexicon Experience Language has started to surface after many months of hard work. And it’s done it through the front door :)

Lexicon - the new Liferay Experience Language

You may be wondering, what is Lexicon? Lexicon provides designers and developers with a set of patterns (visual and interaction) that are connected to each other and focused on the Simplicity, Efficiency, Consistency, and Beauty. These patterns can be carefully combined, like lego pieces, to obtain the desired user experiences.

Lexicon is a new design language designed to be fluid and extensible while providing a complete collection of visual and interaction patterns. It has been created by our UX team to create outstanding user experiences on top of Liferay. Liferay 7 includes an implementation of Lexicon as an extension of the Bootstrap framework.

If you are able to attend DevCon, or one of our upcoming Symposiums, don’t miss the presentations where Lexicon will be formally announced. A brand new website with all the information will be presented and will be launched soon after.

You are curious about how it looks? Here are some screenshots:

Lexicon is design to be stunning and beautiful, optimized for the most common operations and taking the best from the most popular modern UI patterns out there.



It’s obviously designed to work well with tablets...


And of course with smaller screens too, since it was created with a mobile first approach.

We are working on redesigning the user experience of all of Liferay’s applications (and there are quite a few) to adapt it to Lexicon. The Alpha 1 release we already have the first version for several administration portlets:

  1. Web content

  2. Forms

  3. Dynamic data list

  4. Tags

  5. Categories

  6. Recycle Bin

  7. Image Selector

The work on this and several other portlets is ongoing so you can expect many further improvements in the upcoming releases. Meanwhile, feel free to keep the feedback coming.

Platform Infrastructure

Liferay 7 now supports Java 8. The main work here has been in testing, which have caught a few minor (but some highly visible) issues. If you download Alpha 1, go ahead and try it with Java 8. If you find any issues please report it.

Additionally we have done some simplifications to the scripting engine. Instead of shipping out of the box with many different language options, from now on Groovy is going to be our scripting engine by default. The other engines are still supported, so in the case you need any other one, you just need to install it.  

Improvements in WCM

Web Content can now be sorted by priority in Asset Publisher

First of all, we would like to thank Jan Eerdekens and its great contribution to make Liferay better. Everything started when he catched Julio Camarero’s attention by writing this forum thread Liferay - The missing parts: web content article priority, we invited him to contribute the improvement and now asset publisher allows you to filter web contents using priority. We love our community!!! You are great guys!!

The priority of a web content can now be set within Web Content administration, editing the web content and setting the priority within the Categorization options:

The Navigation portlet gets bootstrap super powers

A set of different bootstrap nav styles have been included in the navigation portlet as application displays templates. From the configuration option in the navigation portlet, those styles can be selected to decide which style will be applied to the page name within the site.


Ability to group Site Pages

This is a commonly requested feature and common extension that is now provided out of the box. Liferay supports having an unlimited number of site pages organized in a hierarchy, but up until now all pages were assumed to have some content.

Now, site administrators can create pages of type “Node” (tentative name, suggestions welcome) that have the only purpose of grouping child pages.

By having this new page type the default theme can be smart about it and...

  1. Don’t show a link to it, instead make it a drop down

  2. Only show it in the navigation once it has some child elements

If you were hard-coding this type of behaviour for specific pages in your custom themes, there is no longer a need to do so. That will make your themes much more reusable!


Improvements in Calendar & Workflow

Workflow of calendar events can be configurable via Kaleo

We added a new resource “Calendar Event” in the Workflow configuration options, there you can select the workflows that calendar events have to follow


Later, when you create events in the different calendars you have access or you manage, they will follow the assigned workflow to them, and those events can be managed by the user from “My workflow tasks” option menu:


The user can assign to herself the tasks, update the due date or it can assign it to other users who have same roles as her. A comment can also be included on the assignment pop up window:

In addition to these highlighted improvements, Alpha 1 includes +100 stories finished since M7 was released the last month.

So, what are you waiting for? Go ahead and download Alpha 7 now from sourceforge and keep the feedback coming.

Esther Sanz & Jorge Ferrer

Liferay 7 Milestone 7 - the last milestone release

Company Blogs 20 agosto 2015 Da Jorge Ferrer Staff

If you thought August was being a bit boring in terms of news, here we come to spice it up with yet another new milestone release on our road to Liferay 7. And it’s not just any release. This will be the last milestone release of the series. Yup, you’ve heard right; the next release will be our first alpha release already. So this is a great moment to take a look at the ongoing work and give us your feedback through the Community Expedition program.

Milestone 7 includes +180 stories finished since M6 was released the last month. This entry will explore some of the most relevant features and improvements.

New default look and feel

It’s almost a tradition to have a new version of the default look and feel with each version, and Liferay 7 will not disappoint anyone in this respect :) This milestone finally contains a first version (not fully finished yet) of the new look and feel that will be included in Liferay 7.

First, the default theme for sites (known as classic) has been updated to provide make provide a modern, mobile friendly, flat and very clean look. We are also working on making this theme much more configurable, than in previous versions of Liferay, so that it can be easily reused out of the box. This is how it looks for a non logged-in user:



Ok, let me make a confession. It doesn’t look this good in this milestone just yet. Most of the technical aspects of the implementation are there, but we need to do quite some polishing on the CSS side.

Another relevant note is that we are also working on a new “portlet decoration”. That is, the “box” around each portlet (aka “application”) that is added to a page. This is not shown in the screenshot nor is included in the milestone, but will be available in the first alpha.

We also updated the look and feel for the administrative areas of the product. All of these areas can now be easily navigated using the new Product Menu (more on that later) and when accessed, makes very efficient use of screen real estate, as seen below:


As you can see it’s been designed to be mobile friendly (in fact it was designed with amobile first approach.

For those more technically oriented, you will be interested in knowing that these new themes are based on a new Bootstrap theme—of our own making—called Atlas, that implements our new and shiny Liferay Experience Language called Lexicon. But we’ll let you know more about that later on ;)

New Product and Control Menu

This is an improvement that has been in development for more than a year including hundredths of mockups and many user tests. The goal is to provide a versatile and flexible way to navigate through all areas of the product as well as access administrative functions in a way that doesn’t alter the desired design and is fully mobile friendly.

These functions were previously provided by a combination of the Dockbar and some navigation menus in Site Administration and Control Panel. In Liferay 7 we have organized things in three components (all of them mobile-friendly) with very clearly defined responsibilities:

  1. Product Menu: Provides all the out-of-the box navigation throughout the administration tools of Liferay (or that you might install). That includes: all tools to administer a site, applications of the Control Panel, personal applications, etc. It also allows quick access to sites that the user is a member of or has administration permissions. The product menu also replaces the independent menus that Site Administration or Control Panel used to have. The Product Menu is invoked from a site by clicking a menu icon in the lower left corner.

  2. Control Menu: Includes all the controls to edit or manage the currently displayed page. It includes buttons to: add portlets (aka applications) to the page, edit its configuration, preview on smaller devices, check staging, and a few other options.

  3. User Portlet/Widget: Shows the “Login” link or the currently logged in user name and picture. It can be placed anywhere in the theme to fit any design and can be easily customized via CSS. This portlet replaces one remaining function of the Dockbar in a way that works much better with any design.

The following screenshot shows all three components; the User Portlet in the upper right corner, as it’s displayed in the default theme, the Control Menu at the bottom, and the Product Menu opened on the left side.


One very important aspect is that we have designed the Product Menu and the Control Menu to be fully extensible. Even fully replaceable if that’s what you need. We’ll have a DevCon session and specific documentation on how to do that.

Right now, all these components are, going through a series of usability tests, so expect some changes. We care about your input and feedback, as the user, so we would like you to give it a test run and let us know what you think.

Great image selection experience

One of the most common operations while authoring content—either formal content or collaboration content (blogs, wiki, …)—is adding images, videos or any other type of attachment. Previously, Liferay used to leverage a selector from the CKEditor project, but let’s just say that it had quite a bit of room for improvement. So much that replacing it was the #1 feature request on our Ideas board.

We discussed replacing it quite a while ago, but we wanted to create something really good, since this operation is so common. After many design sessions and usability tests, we are really happy to finally present the result. This selector will now be used throughout Liferay’s portlets, whenever the user can select an image or any other type of file.

An example of this selector is the selection of a cover image for a blog entry:



Images, can simply be dragged into that area or the user can click the blue button to select a file. And they will be presented with the image selector. The first view of the selector is always designed to display the images more appropriate for the given context. In this case, since the user is in blogs, it will show what we call “Blogs Images”—an images repository that every blog has, to allow authors to quickly add images.

But of course, it’s also possible to reach out to the full Documents & Media repository, which contains images (and other document types) reusable across applications:


Note that the image selector has full search integration, by using the text field in the upper right corner. But, if the user prefers, they can browse through any folders that exist.

Once the user has found the right image, clicking it opens an image preview. We want to make sure the user always picks the right picture:

From this view, the user can go back and forth to other images. In case the user didn’t pick the right image. The user can also go back to the list of images through this view.

Clicking “Add” will select the image right away; no intermediate dialog with complex and difficult to understand options. Whatever options may be needed, will be presented later, after the image is inserted.


One additional common need that we have identified, is when our customers have pre-existing repositories of images that they want to integrate in their Liferay based sites and portals. Previously, it was hard to do this type of integration for selecting an image;  the resulting user experience was not very good.

In Liferay 7, this use case is very well covered through extensible image selector “Views”. Each “View” appears as a tab which will show up (or not) depending on the context. In fact, the tabs in the first screenshot (“Blogs Images”, “Documents & Media” and “Upload Image”) are all views; so it’s even possible to remove them if desired. Each “View” can be implemented as a small module following a well defined—and semantically versioned—API; which will make it easier to keep compatibility of views, even across Liferay versions.

We would actually like to promote the creation of 3rd party selection views that integrate from common sources of images such as Flicker, Google Images, Pinterest, etc. If you don’t have an App in the marketplace yet, this could be a good place to start.

ECMAScript 2015 support for JavaScript lovers

For those of you who like and follow front-end development trends, we’re certain that you’ve heard about ECMAScript 2015; which brings many significant improvements to JavaScript. We are pleased to announce that, now in Liferay 7, you will be able to:

  • Write ES2015 code which runs on IE9+, Safari, Chrome and Firefox (thanks to Babel).

  • Install 3rd party modules via Bower and use them in your Portlets from both JSP and JS files.

If you want more details to explore all the possibilities, don’t miss Iliyan Peychev’s blog entry Introducing ECMAScript 2015 support in Liferay Portal 7—it contains a video demo!!!

More features and functionality in AlloyEditor

This milestone contains a new version of everyone’s new favorite editor, AlloyEditor 0.4.0. First, tables can now have headers, which, combined with some bootstrap classes can help authors create very nice looking tables with little effort. Second, it’s now possible to paste images from external sources directly into the editor.

Additionally, there have been improvements in accessibility and it is now it is possible to use almost every CKEditor plugin, out of the box.

Document Management storages extracted as modules

Liferay’s Document Management service (used by Documents & Media as well as any other application that uses its file storage service) has been providing several underlying data stores. Since this milestone, each of these store are provided as separate OSGi modules:

  • Advanced FileSystem

  • CMIS

  • DB

  • FileSystem

  • JCR

  • S3

This makes it much easier manage; leaving only the ones you need or replacing them with your own implementation.

If there are several data stores installed, as will be the case out of the box, a portal administrator will be able to use the configuration UI to select the ones that will be used.

Service Builder code now uses Declarative Services instead of Spring for dependency injection

As you might know Service Builder is our magic internal tool that autogenerates much of the code to implement backend services; it links the services together and exposes them locally and remotely. In the very first version of Service Builder, it generated EJBs, later we switched to Spring, and now we are taking the next step by using the much more dynamic “Declarative Services” (DS, for short).

Spring is still used for other useful functions such as transaction management, but for dependency injection, DS offers key functionality that all developers extending Liferay will benefit from: the ability to extend or replace components (“beans” in Spring’s terminology) at runtime from any module without restarting the service. This change will increase Liferay’s extensibility very significantly. Previously, this could only be done with an ext plugin, did not manage conflict resolution very well, and required restarting for any changes to take effect.

If you have been following the changes to Service Builder over the last months (or you are a fan of technical details) you may have noticed that up until now, Service Builder used OSGi Blueprint. Blueprint was initially developed by Spring Source to add dynamic capabilities to Spring based on OSGi and was later donated to the Eclipse Foundation. So it seemed like an obvious choice for us. However, we have since realized that the more modern model of Declarative Services was more flexible and was easier to understand and use for all developers.


That was our selection of features for this release, which, as you can see has updates for all tastes: designers, administrators, frontend developers and backend developers. However, keep in mind that this is just a selection of the improvements from our list of 180 new stories, but if you are interested in learning more, please check the full list.

We hope you like these improvements and the new version as a whole. If so, go ahead and download Milestone 7 now, from sourceforge, and let us know what you think, by joining the Liferay 7 Community Expedition.

From now on, we are focusing our attention on testing, testing, and testing, with the specific goal of making Liferay 7 the highest quality release ever. We are also putting a big effort into making upgrades—both data and code—as easy as possible. If you have a portal running on Liferay 6.2, get ready to perform a test upgrade to Liferay 7 soon (we’ll let you know when). You may also see some new features come in as new versions of the many modules that form Liferay 7, because, well, that’s one of the great benefits of having made Liferay so modular, right?

Esther Sanz & Jorge Ferrer

Liferay 7 Milestone 6 - Getting ready for the launching pad

Company Blogs 30 giugno 2015 Da Jorge Ferrer Staff

Together with the summer season and the sunny days the sixth milestone has come too. We are getting closer to the end of the year, and this will be one of the last milestones so all development teams are working on finishing some of the features and improvements that have been months in the works to get everything ready for the alpha/beta cycles. This milestone comes very shortly after 5 but we wanted to make sure you had an opportunity to provide feedback through the Community Expedition program on a few but really cool features. I hope you like them.

This milestone includes +130 stories finished since M5 was released the last month. This entry will explores some of the most relevants features and improvements.

Forms, Structures & Templates

A greatly demanded feature that has been several months in the oven is support for versioning of both structures and templates. It will work similarly as versions of articles. You can start the work on a draft version, approve it later or revert to a specific version.

A second large improvement we are working on in this area is a new form building experience, easier to use and more powerful. And you can already taste some of that already in this milestone.

First, you can now create multi-page forms and organize the fields in advanced form layouts by creating rows and columns.

Second, publishing any form in a site is now also easier with the new 'Form' portlet:

And you probably guessed this already, but we’ve also embraced modularity here: the form rendering, form validation and field types are OSGi modules, so you can extend it to adapt it to your own needs. Whatever they are.


One frequently used capability that Liferay provides when building a site was to be able to embed a portlet from a theme, so that it’s visible in all pages. This is often done for breadcrumbs, language, navigation. We’ve now added the ability to configure these portlets just like any other through the UI, instead of having to hardcode the configuration in the themes. We are actually leveraging this ourselves in the default theme where the breadcrumb is being embedded:


When the configuration is changed, it will be shared in all pages of the site where the portlet is shown.

New Search Infrastructure

This is yet another really big improvement that it’s been several months in the kitchen: starting with Liferay 7, ElasticSearch will be replacing Lucene as the default search engine!

And this is not just a one by one replacement, it comes filled with many many improvements, both functional (to increase search accuracy) and non-functional (to improve performance and facilitate clustering of indexes).

If you are interested in looking at the technical details check LPS-56180.


There are also many more technical improvements, including an upgrade to Tomcat 7.0.62, upgrading to reCAPTCHA 2, extracting more and more features as modules, adding new Component based extension points, better configurability through the new settings API and much more.

If you browse around you will probably start seeing many more improvements, but most are still considered half-baked yet, so we preferred to not highlight them. In any case, feel free to provide feedback on them if you think it can help make the product better.

That's it, f you haven’t done it yet go ahead and download Milestone 6 now from sourceforge. And remember that this year your feedback is more useful than ever since you can talk directly with the developers of each feature by joining the Liferay 7 Community Expedition. Go ahead and participate to make sure Liferay 7 fits your needs in the best way possible.

Esther Sanz & Jorge Ferrer

Liferay 7 Milestone 5 - Get involved while it’s hot

Company Blogs 16 maggio 2015 Da Jorge Ferrer Staff

Here at Liferay we don’t stop and we just took out of the oven the fifth Milestone of the upcoming Liferay 7 release. If the previous milestone marked the beginning of the Community Expedition program which had a great success, with this one we would like to encourage even more people to get involved and provide their ideas as we get closer to the beta cycle. Just follow the link above, become an explorer and choose the areas you would like to try out.


This milestone includes +210 stories finished since M4 was released. This entry will explore some of the most relevants features and improvements.


One of our main areas of focus has once again been in modularization. This effort is turning Liferay from being a monolithic web application to a set of highly coordinated modules (think, microservices within a JVM). As we make progress we can’t avoid being excited by the opportunities this is going to bring to Liferay and anyone using it.


This milestone release already contains 150+ modules, which can be updated independently and deployed and undeployed on their own (as long as their declared dependencies are met). When you download the milestone, check the osgi directory within ${liferay.home}. You can undeploy features directly just by moving a JAR file out of there (which will cause all other modules depending on it to stop nicely as well). You should also try doing a “telnet localhost 11311” when Liferay is running to connect to the GOGO shell which allows performing all short of management operations on the modules and its components. This is one of the really nice things of following standards, even though we are building nice UI tools for the most common operations, we can also rely on 3rd party tools for advanced operations as well :)


Web Content Management

Most of the work regarding Liferay’s WCM capabilities for this milestone have been under the hood, with many portlets and transversal features extracted out as modules. Some examples of this are asset publisher, recycle bin, content search, web content admin, search, site templates, page templates, roles selector, sites admin and sites settings. But the team wasn’t happy just modularizing, they also threw in improvements in configurability, added friendly URLs to all portlets and put a big emphasis on exploratory testing and test automation for each new module to ensure the highest quality.


The team taking care of WCM has big plans to improve the experience for building modern web sites so you will also see UI improvements here and there as the underlying improvements start to surface.


Staging is one of the most powerful features of Liferay, used in some of the largest sites out there, but it’s also by its very nature one of the most complex ones. The main focus for Liferay 7 is being in making it rock solid even in the most extreme scenarios.

Related to this, we have realized that because there are currently so many options when using Staging (even if we reduced them for 6.2), it’s sometimes easy to get in trouble. Because of this we have started a process to simplify the UI for the most common operation. The first step is related to the “Publish to live” operation. From now on, the default screen will just offer one option, which publishes *all* changes since the last publication to live.


Basic Publication.png

If you are wondering where the previously existing options went, don’t worry, they are still available under an “Advanced Publication” option:



These UIs are still not final, but already show our goal of provide an interface that guides the user towards making the right decisions at all times. when using staging.


Alloy Editor


If you have already enjoyed the wonders of AlloyEditor in previous milestones you will be happy with the new version (0.2.6) included in Milestone 5. And if you haven’t seen it yet prepare to be blown away by a much better experience in online authoring.


This version includes some under the hood changes (it’s now powered by React, removing the YUI3 dependency and has a new Ocean skin), but my favorite improvement is the really nice support for creating and managing tables. You can use it to build tables of any type, including complex combination of cell merging, adding or removing rows/columns on the fly, etc.


Click on the table icon, select the number of rows and columns and get an initial table inserted which you can then continue manipulating with inline options to adapt it to your needs:

Another feature that I really like is being able to style the table (for example using the styles that Bootstrap or some defined in a custom theme). That’s not available in this milestone yet (it just lacks some configuration) but you can check it out in AlloyEditor’s site.

You can however already see the support for configurable styles in any regular text. Just double click on any text and you will see a dropdown similar to this:

Blogs_-_Liferay (1).jpg

But that’s not all, here are some other really cool new features of this version:

  • Automatic link detection

  • Adding images directly from the camera

  • Image redimension

  • New developer APIs:

    • Selections have been exposed via AlloyEditor.Selections.

    • On adding buttons and toolbars, the developers have full access to the same API which the internal buttons and toolbars use.


Oh, and I almost forgot, we have also put in place a mechanism that allows configuring AlloyEditor (and other WYSIWYG editors) just by dropping a module with the desired configuration. Documentation is coming soon, but it’s easy as pie :)

Collaboration Suite

Several improvements were done to the Knowledge Base portlet which is now being used to host Liferay’s official documentation within the Liferay Developer Network. The most relevant is the ability to import many articles at once with a ZIP file. These improvements are being made available through a new version of the Marketplace App that was just released, although you can also deploy it from sources into Milestone 5.


The user experience of the comments system has been improved by leveraging Alloy Editor which lets the user focus on what he wants to write while visualizing the final style. Comments now automatically detect links and support bold and italics for advanced users (who know the key combination to apply them). Here is what the user sees at the top of all comments:


And here is the result after typing a few words:


In addition to this, the two previous visualization styles (tree and flat) for the list of comments have been merged into a single one that displays nested conversations but deals with scalability in an smart way.

A final cool feature that has been in the oven for a while is the ability to mention other registered users using the typical @ sign which will start an autocomplete dialog. When there is a mention within a comment it will be automatically translated to a link to the user profile of the mentioned user. This behavior is extensible (has been implemented as a module) so that you can choose different sources of users or change where the link points to.

Web Services

A new infrastructure has been included in this milestone that simplifies building SOAP based or RESTful web services on top of Liferay with strong security and using the latest JavaEE standards such as JAX-RS and JAX-WS.


Wrapping up

Of course there are many more small improvements that will make Liferay 7 the most extensible and easy to develop on top of ever. Get involved now to see it for yourself by downloading Milestone 5 now from sourceforge. And remember that you can get directly in touch with the developers of each of the features listed above (and many more) by enrolling in the Liferay 7 Community Expedition and providing your feedback there.


Jorge Ferrer & Esther Sanz


Liferay 7 Milestone 4 - The Adventure is getting serious

Technical Blogs 25 febbraio 2015 Da Jorge Ferrer Staff

Did you like what you saw in previous milestones? You didn’t feel there was enough meat to be worth your time? Get ready for Milestone 4 which comes bundled with many improvements and new features. Not only that, with this release we are launching the Liferay 7 Community Expedition program which will allow intrepid adventurers to work with the Liferay developers to find bugs and provide early feedback on the new features.


This milestone includes +130 stories finished since M3 was released. Let’s take a look at the most interesting improvements.

Web Content Management


There are several super-cool feature in the design kitchen, but for now the work is being focused on modularizing and adding new extension points. As a result of these work many portlets have been converted to OSGi modules (RSS, XSL Content, Nested Portlets, IFrame,  Sitemap, Breadcrumb, Tags Navigation, Tags Administration, Categories Navigation,  Categories Administration and Web Content Display) which among other benefits will allow us to improve them much faster than before going forward (since it won’t require a new release of the whole product).


In addition to this, one small frequently requested feature was added: Ability to translate the site and name description.




In a previous milestone I described how in Liferay 7 it will be possible to create custom export/publication configurations. Early feedback has shown that this feature can be so frequently used that in some cases there will be many of them. Because of that we have added the ability to search through the saved export configurations.


Also, we’ve made it easier to select which configuration a site admin wants to use when publishing right from the dockbar:



WYSIWYG Editing  


The highlight of Milestone 2 was Alloy Editor and the feedback we have received so far has been great. However there is one feature that several power users reported missing: the ability to edit the HTML code directly. We didn’t want just to attend this request but we wanted you to be as amazed as many people were with the new WYSIWYG edition. Because of this our frontend gurus have been using their great skills to good use in order to create the best HTML editing experience you’ve seen in this type of environment.


You can check it out in the blogs portlet (which is the first to adopt Alloy Editor, more will come later). You can now see an small icon in the upper right corner to enable the code editor:




When you click it the WYSIWYG editor will be converted to a code editor, with numbered lines and syntax highlight (courtesy of AceEditor).




And of course if you are used to coding with a dark background (quite common these days) we have you covered as well. Just click on the small moon icon in the upper right corner:




But this is not all. Several of us thought that for certain cases you want more space (the full screen) to do the editing. And since we are just making a wish list here, what if you could preview the result as you are typing your code? … You have it :)


Pretty neat, right?

We are quite proud of the result and hope you like it. We actually got so excited about the result that we might take it a bit further, but I will keep the surprise until next milestone.




In Milestone 3 we presented the new out of the box support for geolocalization. We received some pretty good feedback that is making us rethink the feature backend a little bit. While we do that we have improved the presentation logic so that the map shown to geolocalize the assets is configurable to be OpenStreeMap, Google Map or a custom implementation.


Document Management


Google Docs can now be linked inside the Document Library alongside other documents. When this feature is enabled a new option appears in the Document Library to add a Google Doc. A dialog will appear letting you browse your Google Drive and choose a document to include in the Document Library. The document can also be edited from the Document Library.


Collaboration Suite


Three small but useful improvement were made to our collaboration suite:

Developer oriented improvements


To finish I’d like to highlight a few new extension points and API improvements for developers:

  1. Ability to add custom icons or menus to the portlet decoration (aka portlet box or portlet borders).

  2. New API layer that allows manipulating form definitions and values as objects, instead of having to manipulate the underlying XML directly.

  3. Implemented the capability of adding new field types for DDM through OSGI modules (See the Text type for an example). We hope to see a lot of third party types.



That’s it, if you haven checked previous milestones I hope this large list motivated you to go to the downloads page for Milestone 4 at sourceforge and get it. If you want to get really involved in testing it and giving feedback, check the Liferay 7 Community Expedition program and join many other enthusiastic explorers :)


PS: I'd like to thank Esther Sanz for all her help gathering the data presented at this blog. Without her I wouldn't have made it on time :)

Liferay 7 Milestone 3 - Happy Year-End Hacking

Technical Blogs 23 dicembre 2014 Da Jorge Ferrer Staff

It’s the end of the year season and most programmers take a few days of to spend time with family and/or friends and of course check out some new technologies. While we know there are many exciting new techs to choose from, we wanted you to have at least one more option to choose from by making available a new and shiny milestone of Liferay 7. This is a great opportunity to see the latest developments that are getting so many people excited after our symposiums and DevCon.


This milestone includes 160+ stories finished since M2 was released, but the one that probably shines the brighter is the out of the box Geolocation support. As Juan Fernández mentioned in his blog, this milestone already contains the capability to geolocate web content, documents & media and dynamic data lists. The location can be setup to be entered manually by the user (entering an address) or automatically using the HTML5 geolocation feature.


Introducing the location in a web content

This becomes a really cool feature as soon as you start displaying a list of assets in a map, something that you can also do out of the box by picking the mapping template of Asset Publisher:

Displaying geolocated assets in a Map with Asset Publisher

And in case you were wondering, you are not tied to Google Maps. You can also use OpenStreetMaps or add any other maps provider. If you haven’t done so yet, go ahead and read Juan Fernandez’s blog about the new geolocation support. This capability will be added to other content types later including your custom ones, through Custom Fields, so take a look at it now and provide your feedback, since you will get a lot of benefit from it :)


The second highlight of the release is how the process to modularize more and more parts of the core using our OSGi-based infrastructure is gaining a lot of speed. As proof of that here is an screenshot of the directories that hold the extracted out modules so far (the collapsed dirs just contain one module inside with the same name and -web as a suffix):


Finally here are some other smaller improvements that I considered worth of mentioning:

  • Web Content types have been converted to a categories vocabulary (with an automatic upgrade process for those previously using Web Content types).

  • Added back the ability to download Structured Web Content as an XML from the Web Content administration UI.

  • Improvements in the default configuration: Message Boards notifications will include the name of the poster, blog lists will use abstracts instead of full content.

  • Added support for “Likes” for any asset type in addition to the two existing rating systems: stars and thumbs up/down

  • Alloy Editor which debuted in Milestone 2 has also received improvements, specially based on the feedback in the blog entry and during Liferay DevCon 2014. In particular two new buttons were added to the editor: for writing code and for quotes. Additionally some issues were fixed, such as: AE-75. Work has also started to implement larger improvements such as a code editor.

  • Many improvements to the APIs of DynamicDataMapping (DDM) are also included in this release, specially increasing the features exposed through remote APIs.


That’s it, if you are eager to check it out, just go to the downloads page for Milestone 3 at sourceforge. I hope you enjoy it and please send us all of your feedback :)


Happy Season to everybody!

Liferay 7 Milestone 2 - The adventure continues

Company Blogs 29 ottobre 2014 Da Jorge Ferrer Staff

It's been around 2 months since Milestone 1 and we are now ready for the second public deliverable of the ongoing Liferay Development: Liferay 7 Milestone 2. As usual it can be downloaded in Sourceforge’s downloads pageIf you prefer to get them from a Maven repo you can get it from Liferay’s maven repo. If you prefer to get it from GitHub you can use the 7.0.0-m2 tag.

If you didn't download Milestone 1, no regrets, just read again its highlights and download with Milestone 2. Compared to the previous milestone, this one includes mainly refinement and bug fixing of the new features, as well as quite a lot of work doing refactorings and starting new cool functionalities that will surface in the milestones to come.

One significant new improvement that you can already see in this Milestone is Alloy Editor. Alloy Editor is a new project lead by Iliyan Peychev which aims at greatly improving the user experience when creating WYSIWYG content. It started drawing inspiration from and has outgrown it quite a bit. It uses CKEditor under the hood but provides a new UI on top of it. We have started by applying it to blogs (since it's a simple case). Here are some screenshots of how editing a blog entry feels like in Liferay 7 Milestone 2.

1) This is how the editor looks when it's first open:

2) This is how it looks once I've entered a title, subtitle and some content. Look at the plus within a circle. That's what allows you to insert stuff, such as images (which you can also just drag and drop inside the text):

3) If you want to add format to some text, just select it and a nice simplified toolbar will offer the format options.

4) All non-content related fields are organized in a secondary tab called "Settings":

We are very interested in getting feedback on the authoship experience in blogs, since our goal is to later apply Alloy Editor to other applications.

For a complete list of all improvements done in this milestone visit the board: Liferay 7.0 M2 New features grouped by Area.

Send us your feedback about Alloy Editor or any other feature in any Liferay 7 milestone through the Beta Testing forum category

Liferay 7 Milestone 1 - Only for the really adventurous

Company Blogs 29 agosto 2014 Da Jorge Ferrer Staff

The word is out in Twitter, we have released the first development milestone release of Liferay 7. This is a call for really adventurous developers to try it out and give us your feedback. Here are the answers to the questions you may have about the release.


So… is Liferay 7 close to being released?

Nope. Our current thinking is that Liferay 7 will be released in the second half of 2015. But we will be releasing several milestone releases before that.


What’s the goal of milestone releases?

We want to give adventurous developers an opportunity to take a sneak peak of the new features and frameworks as they are being developed. This will give *you* an opportunity (directly or by finding a friendly adventurous developer) to provide early feedback and help steer the release.


A second goal, which will be especially important for the first milestones is to fine tune our internal release process now that the product and team has grown to quite a large size.


What’s the quality of Milestone 1 like?

Don’t expect it to be stable other than for testing out some of the new features. Of course never run it in production.


The milestones are always built from our master branch and while we work towards making it stable, it’s definitely not for running in production (and at times even for testing). We will make efforts to make it stable to allow for testing but since there is no testing phase there might be last minute changes that break things. If you find them, congrats! You are a real adventurous developer exploring unexplored territory ;)


Ok, cool, but what’s new in this release?

Here are some highlights that we would like you to look at:

  • WCM:

  • Collaboration & Social:

    • Ability to @mention users from any portlet that uses a WYSIWYG editor

    • Applied portal notifications to the subscriptions of Blogs, Wiki, Message Boards, …

    • Ability to Geolocate Web Content and documents. Also a new template for Asset Publisher to show them in a map.

  • UI Infrastructure

    • Update to Bootstrap 3. Frontend devs rejoice!!

    • SPA Enabler: You really need to try this out. Thanks to this new cool technology (based on our own SennaJS and AlloyUI Surface) all portlets automatically become Single Page Applications and users can navigate through them without reloading the whole page. Expect huge gains in both speed and data transmitted (which is great for mobile access)

  • Platform Infrastructure

    • Replacement of Lucene with ElasticSearch as the default search engine

    • Support for testing plugins and OSGi modules using Arquillian

    • Exposing many of the extension points in and all extensions of liferay-portlet.xml as OSGi components.

    • Exposing many new extension points like Portlet Filters

    • Ability to develop complete portlet as OSGi modules

    • Ability to create standard OSGi modules that invoke Liferay’s core services API easily (it’s no longer needed to create a web app to do this, simplifying the task significantly and reaching a wider Java dev audience).

    • Ability to use Service Builder in OSGi modules

    • Ability to expose any Java Service in an OSGi module as a JSON Web Service (even without using Service Builder!)

    • The prototype release of the new Eclipse Equinox Http Service implementing OSGi RCF 189 - Http Whiteboard

    • Support for JSPs in OSGi modules

    • Several smaller portlets extracted from the core

    • The work to extract Liferay’s large core apps as OSGi modules has started although none of them have not landed in master yet much of the infrastructure is already in place (Expect more news in M2)


There are also many more small improvements and technical changes, since we organize our work in the form of Stories we’ve prepared a page with a list of all stories organized by area in the following URL: (Thanks Esther for setting this up!)


Where can I download it?

At the usual page in Sourceforge’s downloads page. If you prefer to get them from a Maven repo you can get it from Liferay’s maven repo. If you prefer to get it from GitHub you can use the 7.0.0-m1 tag.


That’s it, we look forward to hearing your FEEDBACK!


PS1: Big thanks to James Falkner, Julio Camarero, Nate Cavanaugh for proof reading and help make the entry more complete

PS2: The source for the cover image is

Update (Sept 1st), added link to the GitHub tag to the "Where can I download it" section and credits for Esther on the structure will all new tickets in the milestone.

New in 6.2: Bootstrap.... even in Web Content

General Blogs 18 novembre 2013 Da Jorge Ferrer Staff

Continuing with my series of "New in 6.2" entries, today I want to put the focus on a more technical aspect of the new version: the fact that it provides support for Twitter Bootstrap out of the box. Some of the benefits of this are:

The first two points are more technical and for an audience of developers, so they'll be covered in more detail elsewhere, so I want to focus on the last point. The ability to use bootstrap for webcontent is actually a side effect of its use everywhere else, but it's definitely a very useful side effect :)

Since Bootstrap already has good documentation that you can access following the links above I won't try to do an in-depth explanation. Instead I've chosen 3 examples of content where I think applying bootstrap can be useful. 

#1 Nicely formatted tables

When you create a table in a new web content it looks more or less like this:

Which looks ok, but not so good. In order to apply some of the bootstrap you will need to have a little bit of HTML knowledge. While editing the web content click on the "Source" button. Locate the <table> tag which will look something like this:

<table border="1" cellpadding="1" cellspacing="1" style="width: 500px;">

And change it so that it looks like this:

<table class="table table-striped table-bordered">

Each of these values of the class attributes provides one feature:

  • table sets the base styles
  • table-striped colors alternative rows differently
  • table-bordered draws the borders around the table. 

It's worth mentioning that the WYSIWYG editor is not aware of bootstrap, so just getting out of the "Source" mode won't be enough to preview your changes. What you can do is click the "Basic Preview" button at the top of the web content form. 

Just by making this small change your table will look like this:

If you are a bit averse to HTML (or your content is so large that editing the HTML is a pain) you can also achieve the same effect by double clicking in the table to open the properties dialog. Click on the advanced tab and in the "Stylesheet Classes" field enter "table table-striped table-bordered " as shown in the next image:

Clear any styling (specially widths) in other fields and click ok. Preview the content or publish it to check the same result was obtained.

If you are interested in more options that bootstrap tables provides you can check it's official documentation.

#2 Image effects

Bootstrap provides 3 nice effects for images: rounding the borders, making them a circle and adding a polaroid-like fame around it. In order to benefit from this you don't even need to edit the HTML. Go ahead and insert an image with the image dialog as you normally would. For example, let's pick an image of Brian from our about us page. Click the image button in the WYSIWYG editor toolbar. After uploading the image or introducing the URL click the advanced table and enter one of the following values in the "Stylesheet Classes" field:

  • img-rounded for rounded corners
  • img-circle to get an image with the shape of a circle
  • img-polaroid to get a nice frame around the image

If there is any value in the Style field, clear it to avoid conflicts with the bootstrap styles. Here are the results I got for each of the styles:

Cool, right?

#3 Responsive layouts and menus

This is the last and most advanced example. Here you will definitely need to have some HTML knowledge. 

The first thing you need to know is that Bootstrap uses a 12 column grid to lay things out in a page. So when using bootstrap you should think of your page as something like this:

You then specify for each item how many columns it spans. Something like this:

  1. <div class="row-fluid">
  2. <div class="span4">...</div>
  3. <div class="span8">...</div>
  4. </div>

You can then add anything in each of those DIV's.  What is nice, is that on smaller screens, like those of phones, the columns will become fluid and display below each other. Instead of doing a simple example like I've done in the previous two cases, what I'm going to try this time is take one of the more advanced examples that are provided in the twitter page. Here are the steps I have followed:

  1. From a Liferay page, click add > content and then create new (Basic) Web Content. 
  2. Give it a title and click the "Source" button in the editor.
  3. Pick one example (I picked the one titled "Fluid Layout"). View the HTML and copy the source code inside the <body> tag (without the <script> tags at the bottom)
  4. Paste the HTML inside the editor.
  5. Publish. 

This is the result:

Three things to note from this screenshot are:

  • Even the most complex bootstrap samples can work inside a Liferay web content. There are tons of possibilities. 
  • But you must use them with care. If you look at the top of the screenshot you will see that the sample I picked added a black bar positioned at the top of the page. This bar hides the Liferay dockbar, which is definitely not desired. I did this to prove how the fact that you can do something, it doesn't mean it's desired :)  In this specific case you can avoid that effect by looking at the HTML code you copied and remove the class navbar-fixed-top. In general try to avoid using the classes that contain the word "fixed" inside a web content unless you really mean it.
  • You may need to do some CSS tweaking so that it looks pixel perfect in your scenario. In this case the menu would look better without the padding, which in the original Bootstrap example remove with a CSS definition in the page.

If you liked this and want to learn more, my recommendation is to read the nice documentation for Bootstrap 2.3.2.


New in 6.2: The new "Side Page Panels"

General Blogs 31 ottobre 2013 Da Jorge Ferrer Staff

In my last blog entry I explained the thought process we followed to improve the Dockbar. What some of you may have noticed is that I skipped talking about three elements that used to be in the left side of the dockbar in 6.1:

So, what happened to them? These options where part of the overall work that we have done to provide a proper Information Architecture for all administration functions a Liferay administrator may need to use. In particular, several of the options that were accessible through the "Manage" menu are now part of the new Site Administration UI.

What has been left are the operations that are related to what the admin is seeing right now, that is, the current page. That includes adding stuff to the current page, adding a new page, previewing the page in different devices (new in 6.2) or controlling whether to show or not display controls.

One other goal we had was to find a way to show these management controls in a way that didn't require a full bar at the top, since that created a significantly different visual effect for admins than for regular users. While that may be fine in some sites, it's very undesired in others. After evaluating several options we decided to use a technique to add the management options for the  "Current Context" to the left side as shown in the image below:

Now, you may be thinking "Wow, that's cool and beautiful, but it may not fit well in my theme". No worries, we thought of you too. The side icons are fully themable. In fact, this representatoin is only part of Liferay's classic theme. If you use "_styled" as the base for your theme you will default to the traditional top bar from side to side. And when you are ready you can switch to the new side icons with a few lines of CSS/HTML as the Classic theme does. Kudos to Nate for making it so easy to choose what better fits your needs.

Now let's take a look at what's inside each of those icons. They all work the same way, upon clicking them a side bar will appear from the left side. This is a new UI pattern that has been introduced in 6.2 that provides a lot of benefits, including the ability to perform operations while in the context of a page, without loosing it from your view at any point in time. Let's look at each of these side panels:

The goal of the "Add Page" panel is to allow creating pages quickly (Just enter the title and click <Enter>) while still providing access to the most commonly used options. Some aspects to highlight here are:

  • We decided to merge Page Templates and Page Type into one set of options, since the difference is mostly technical and the end user doesn't care.
  • Once you select a page type, it's also possible to select some related options. For example, if you select an Empty Page (the default) you can directly choose the layout of columns. If you select a page template you can choose whether to enable propagation of changes or not.
  • As you type, you can see the title of the page appear in the navigation as you type.
  • We used the new "localizer" component which allows specifying the name of the page in all enabled languages of the site.



The "Add Application" panel is similar to the existing one, although with a much more modern look & feel. We have mainly focused on fixing some usability pitfalls such as the problem caused by having the "highlighted" portlets separate from the complete list.




The "Add Content" panel is a very cool new feature. It allows users to search for existing content (or create a new one on the fly) and just drag & drop it to the page. Liferay will take care of choosing the most appropriate portlet under the hood and configure it to display the chosen content. This is a good example of the efforts we are making to speak the language of the user, helping him get his task acomplished and taking care of the technical details transparently.

The Preview pane is another of the new features of 6.2 and allows previewing the site with the most popular device sizes and with any other custom size. While there are plenty of simulators out there, just having the ability to preview any Liferay page one click away is a game changer. You'll see :)

And finally the "Edit Page" pane. One of my favorites, because it packs a lot of page configuration options into an small area. And having the page always visible as you edit its properties makes a huge difference.

That's it for now, I hope you liked these improvements. Looking forward to hearing your thoughts and opinion.


New in 6.2: The new 'Dockbar'

General Blogs 29 ottobre 2013 Da Jorge Ferrer Staff

Hey guys,

The 6.2 release is almost out and I want to use this opportunity to talk about some of the improvements we have done to the dockbar. For those newer to Liferay, the Dockbar is the nick name for the bar that appears at the top of the screen and provides personal and administration options to users. In 6.1, this bar looked like this:

Although, of course it is possible to customize it. For example, here at it currently looks like this within my blog:

In some other portals I've seen people just remove the dockbar except for for administrators. While this is something easy to do from the theme, I always advice people to use it as a last resort. The reason is that Liferay has a very flexible permission system and when a user has some management permissions for the current site or page the dockbar is where those editing options will appear. Liferay has some advanced logic to determine what options to show to each user, but you probably won't want to replicate that logic in your theme to determine when to show the dockbar and when not to.

For 6.2 we wanted to improve the Look & Feel of the dockbar as well as its usability. But we also wanted to make it less intrusive, easier to customize. Among other reasons we wanted to reduce the situations in which there was a need to remove the dockbar altogether.

After doing the proper analysis and quite a few discussions between Nate, Juan Hidalgo, Ed Chung and myself made the most visible decission: In 6.1 the dockbar is a full horizontal bar, that goes from left to right. While this is not so bad for intranet-like environments, it is often not desired in public sites. Furthermore, for regular users who only saw his name in the par it was a significant waste of space. We decided that the bar would float from the right top edge (with some padding) and grow towards the left as needed. Thanks to this, we save tons of screen real state, specially for regular users who just see this:

Let's see this in the context of the whole page. As you can see below, by placing the dockbar to the right the site logo and name become more relevant, which is what is desired in most situations:


If the user belongs to at least one site and has some administration priviledges then two additional menus appear:

  1. My Sites: Shows the sites that the user belongs to, with direct links to the public and private pages (if they exist).

  2. Admin: Contains a link to the Control Panel if the user has access to it and direct links to the site administration sections (Pages, Content, Users and Configuration) that the user has access to. The direct links to each section was one of the last additions based on early user feedback and it has two benefits: It requires fewer clicks to perform any administration operation and it shows the type of things the user will be able to manage for this site even before clicking them.


That's it for now. I'd love to hear your feedback on these changes.

Also, feel free to let me know what other features or improvements of the dockbar or Liferay 6.2 in general that you would like us to cover in upcoming blog entries.

Liferay Architecture: What would you like to know?

General Blogs 3 ottobre 2013 Da Jorge Ferrer Staff

Liferay's architecture is pretty lean, but there are lots of things to learn about it. What would you be interested in learning?

I'm doing a talk next week in Liferay's DevCon in Berlin about Advanced Liferay Architecture. I will also deliver it at the Spain Symposium and the North America Symposium. This presentation will be a follow up of last year's presentation about Liferay's Architecture and the blog series that I have been doing here. Here are the topics that I have in the presentation so far:

  • Caching
  • Request Handling
  • Plugin Architecture
  • Message Bus
  • Asynchronous invocation

Which of these topics is more interesting for you? What other topics would you like me to speak about?

Also, if you can't attend any of the events (and if I were you I would miss them :) send me your feedback as well since I will still write blog entries about these topics.

Please add comments or answer in twitter with your proposals.

Understanding Liferay 6.2 Release Candidates

General Blogs 25 settembre 2013 Da Jorge Ferrer Staff

The 6.2 release is very very close. Those who have talked with the core team about it know that we have been working hard since the 6.1 release to increase the predictability of the releases and at the same time keep increasing the product quality. You have probably already seen that we have released 6 milestones during this time and 2 betas recently. My goal with this blog entry is to explain the last phase of the release cyle: The Release Candidates.

Quoting from WikiPedia:  "A release candidate (RC) is a beta version with potential to be a final product, which is ready to release unless significant bugs emerge". We released the first release candidate (RC1) last Friday and our QA department has been evaluating it in coordination with other stakeholders. The conclusion is that it is still not ready to be called final. So we will build a new releae candidate (RC2) this Friday and repeat the process. We will keep doing this, building one RC every Friday until one is approved as final.

How many Release Candidates will we have? The answer is "it depends" :) What I can say is that everybody involved in the release is working very hard to make the next RC the final one. So RC2 could be the final or we might need a few more (specially since it's the first time we follow this process and there is fine tunning to be done along the way). 

Note that you can help too. Download RC1 now and/or RC2 when it comes out and help test it, upgrade your portlets, etc. Check out the beta 6.2 documentation as well as you do so. There is a new Wiki Page called Known Upgrade Issues to 6.2 Release Candidates where you can add the issues you find or suggestions you have for other people or read what others have written. We really appreciate your help! 

See you soon at the Symposiums and events world wide to celebrate the release!

Update (Oct 30th, 2013): RC6 has resulted to be a very good release and we wanted to make it GA, however there were a very small number of issues we found that we wanted to fix. So we've decided to change slightly the original plan and are just going to fix those issues and release GA directly (skipping a public RC7, although we are really doing an RC every day since Monday). We will most probably start building GA this Friday. Yeah!! :)

New in 6.2: Streamlined administration through Site Administration and the new Control Panel (2/2)

General Blogs 11 agosto 2013 Da Jorge Ferrer Staff

In my previous post I convered the reasons why we decided to streamline the administration UIs of Liferay and in the process review the usability and design of the Control Panel. In that post I already covered two of the key decisions we made as part of this redesign: (1) Extract the "My Account" administration out of the Control Panel and (2) Extract "Site Administration" outside of the Control Panel.

Let's follow up from there with other key decisions.

3. Reorganize the portlets in the Control Panel

Once we've extracted out the portlets within "My Account" and "Site Administration", what do we have left? The remaining tools are those that in 6.1 and previous used to be classified in two sections: "Portal" and "Server". The reasoning for having those two sections was that the portlets that belong to the first manage stuff that belongs to the current portal instance, while the portlets under "server" manage elements that have an effect across all portal instances.

However, the feedback we've gotten over the past couple of years is that this differentiation wasn't very clear, or even highly informative for administrators. Also, some portlets were quite related to each other but were also mixed with other unrelated portlets. For this reason several months ago, Juan Hidalgo our UX Designer based on Madrid, proposed to start brainstorming for alternative classifications. Juan, wrote a card for each tool and pasted them in a big whiteboard (I wish I had a pic but I don't. Juan if you do go ahead and paste it as a comment). After several weeks trying alternatives we were ready to make a proposal, which got interesting feedback from a bunch of people, specially Nate Cavanaugh and Ed Chung. The result was the creation of 4 categories within the Control Panel: Users, Sites, Apps and Configuration. One key thing to highlight is that each of these categories has one portlet that is specially relevant and we expect it to be used much more than the rest in the category (which provide complementary features). Leveraging this, we decided to get rid of the vertical menu and go with a horizontal menu which makes the navigation easier to use. Here is a description of each of the sections along with an screenshot:

  • Users: Contains all portlets related to administering users and user related stuff, such as permissions.
  • Sites: Contains all portlets related to managing sites as well as tools used to build the sites themselves such as site templates and page templates. It is worth noting that within the sites portlet it is possible to fully manage any site (as long as the user has permission) just by clicking on its name. In other words, the site administration UIs of all sites are easily accessible from the Control Panel.
  • Apps: we decided to go along with the overwhelming trend of calling Apps to all extensions to a product. This term had already been adopted by the marketplace so it was good to be consistent. For those used to other terminologies within Liferay, an App can be installed from the marketplace (in which case it can contain one or more plugins) or be deployed locally (in which case it will be composed of one plugin of any type, portlet, hook, web or ext).
  • Configuration: contains all portlets that provide ways to configure the platform. All the configuration performed from here will either affect elements that live outside of a site or will have effect over all sites.

We also decided to provide a frontpage which provides an overview of all portlets available in each of the sections. This provides a quick way to go to any of them in one click. It also provides access to a description of each portlet by hovering the question mark next to its link:

One final thing you can notice in this screenshot of the Control Panel Home is that under each section there is a question and a button that provides access to the most common action that the current user might want to perform. Note that the location of these "Quick Actions" is not final yet.

4. Reduce the number of pop-ups

In 6.1 we introduced quite a few pop-ups to access management UIs as a way to allow the administrator to keep the context. However, after the feedback received and our own UX evaluation we came to the conclusion that we were using pop-ups in situations were they weren't the optimal solution. For this reason, in 6.2 we've replaced many pop-ups with full page reloads, although making sure that the headers and navigation provided proper context as well as a quick way to go back to the previous screen. The general rule we are following is that pop-ups are good for short iterations, but not when the user is going to be working within the pop-up for some time or do quite a bit of clicking around.

The overall experience is definitely much better now and the UI feels much faster.

Note: There are still a few pop-ups that we haven't been able to replace for technical reasons. In particular, the "Manage > Templates/Structures" in Web Content and "Manage > Document Types" in Documents & Media come to mind. We'll replace those later on.

5. Keep backwards compatibility for developers

As you've seen, we've performed tons of changes to improve the usability. However we didn't want these changes to have a big impact on developers. So if you are a developer you will be happy to know that if you developed a portlet for the control panel for 6.1 it will work in 6.2 without any changes. 
This is possible, because under the hood both "Site Administration" and "My Account" are considered to be part of the Control Panel. So in order to create a portlet for any of them a developer just has to add a control-panel-category element within its definition in the liferay-portlet.xml configuration file. We've also made it so that the old category names are automatically converted to the new category names as follows:
  • my -> my
  • content -> site_administration.content
  • portal -> users
  • server ->apps
Here is a full list of the new available categories:
  • Control Panel:
    • users
    • sites
    • apps
    • configuration
  • Site Administration:
    • site_administration.pages
    • site_administration.content
    • site_administration.users
    • site_administration.configuration
  • My Account:
    • my

How can I test it out and provide my feedback?

If you've got this far you are probably interested in finding out how to test this out. It's easy, just download Liferay Portal 6.2 Beta 1 and install it locally. We'd love to hear your feedback either as comments to this blog post or as part of the beta program.

Remaining tasks and aspects under consideration

We are already in the beta cycle of 6.2 so what has been discussed in this blog is quite final. However, there are still some minor UX improvements that are still under consideration and might suffer slight changes. Here is a non-exhaustive list, feel free to give us your opinion:

  • Headers of both Site Administration and Control Panel: we are still not 100% sure of how they look so they may still change.
  • How to let portal administrators know which actions will affect all portal instances: With the new organization it's not clear in environments with multiple instances that some will affect all instances while most won't. We need to find a way to let the user know.
  • Descriptions for each Control Panel section and place the quick actions in a different position that flows better in smaller screen sizes.
  • Navigation witihn the "Sites" and "Users & Organizations" portlets.
That's it, I hope you enjoyed these two blog posts. Next I'm planning a post on the changes we've done to the dockbar, anyone interested?

New in 6.2: Streamlined administration through Site Administration and the new Control Panel (1/2)

General Blogs 1 agosto 2013 Da Jorge Ferrer Staff

Hey guys,

The 6.2 release is getting closer and closer, so after quite a few months without writing a blog entry I'd like to get back starting a new series I'm calling "New in 6.2". In this blog series I plan to blog about new features in the upcoming release and will try to explain our motivations, the challenges we faced and the reasons for the decisions we made. All in the Open Sourse spirit of being as open and transparent as possible. I'm  also encouraging other developers on the team to do the same.

This first blog post will be about a set of improvements with which I've been personally very involved: the redesign of the Control Panel to make it more usable and versatile and to allow it to keep growing without increasing the complexity. This post will go through our thinking process and show the end result. Since it's a pretty large post I've divided it in two parts. Here goes the first one.

Why we started this effort

The Control Panel was introduced in Liferay 5.2 as a way to provide a central location to manage the whole portal, including all of its sites. Previously administrators had to build their own administration UI by manually adding portlets to pages. I think the goal was achieved with great success and almost all of the feedback has been very positive.

However as the Control Panel has kept growing with more and more portlets new challenges have arised. Additionally some companies were approaching us saying that in their particular scenarios the Control Panel was not the best fit. Here are some of these challenges:

  • Losing context: In some portals the fact that the user (for example a site administrator) looses the context of the site when going to the control panel was a big issue (or even not allowed by the company UX policy). A big factor in this context loss is that the Control Panel offered many more options than just administering that one site, another was the quite different look & feel.
  • Too complex: Let's admit it, the Control Panel was becoming quite complicated as it has gained more and more functionality. While this could be alleviated by giving users the right permissions, the fact is that people kept finding it too confusing.
  • Mix of portal-wide administration, site administraiton and even personal account administration: This is an explicit decision we made, so that there was one and only one administration UI for everything. But not everybody feels comfortable with this, specially because personal account administration is available for all users while portal-wide administration is for a very small number of portal admins, so having one single UI didn't allow optimizing for each separately. Site administration was somewhat in the middle of both extremes.
  • Old look and feel: The look and feel had some changes in 6.1 but it was still not so pretty and that fact made it even more intimidating for some users.
  • Empty first page: When going to the control panel the first page is empty and only shows a message. That's not the best from a user experience perspective. 
  • Non-intuitive navigation through administrable sites: the dropdown embedded within the left menu is quite handy for administrators that manage more than one site, but let's admit it, it's weird to have a dropdown within a menu. Specially since what its selection only affects some one of the menu sections.

For these reasons and a few others many Liferay installations were restricting access to the Control Panel (which in 6.1 can be done with a permission) to very high level administrators. In other cases I found people were relying back to the manual addition of administration portlets to regular pages, which I consider more like a workaround than a final solution.

Before digging into the solution let's see the before pic:

The prototype and early decisions

We had been thinking about how to address these challenges for a while but we couldn't find answers for all the questions. Finally this past May during an engineering retreat we decided to give a try and started a prototype. In this prototype we combined several ideas that had been proposed by different people (Nate, Juan Hidalgo, Ed, myself, ...) over the past few months and voilá... we really liked the result. So much that we decided to fully implement it even if it wasn't originally planned for 6.2.

Here are some of the key decisions we made:

1. Extract the "My Account" administration out of the Control Panel.

We call "My Account" to the set of tools that allow a user to manage his personal stuff. By default that includes "Account Settings" (also known as "My Account" in 6.1 and before) and "My Pages". If a workflow engine is deployed, two more tools become available: "My Submissions" and "My Workflow Tasks". And since Liferay is a platform it's possible to add more tools easily by developing a portlet. In the image above you can see the portlet "My Subscriptions" that we use at

Almost all portals provide a way for users to edit his account settings. This means that "My Account" should be available for all users, which contrasts to the Control Panel which is targetted at Portal Administrators. So in 6.2 we've decided to extract it out of there and make it easily accessible through the user menu in the upper right area:

By default it opens a pop-up giving access to Account Settings as well as any other personal portlet. It is possible to make it load as a regular portlet in the current page with a setting in portal. properties:


2. Extract "Site Administration" outside of the Control Panel

The second key decission we made is to extract all site administration tools outside of the Control Panel. In order to do that we have created a new UI, appropriately called Site Administration, that can be accessed from any site. Within this UI all administration tools are organized in 4 sections:

  • Pages: The site pages (public and private).
  • Content: Has an entry for each site application that has content. It also includes other content-related tools such as Categories, Tags and the new Recycle Bin.
  • Users: Tools related to managing users in the context of the site. By default there are two tools, Site Memberships and Site Teams.
  • Configuration: All tools related to configuring the site. The first and probably the most used of these tools is "Site Settings", other useful tools are the new Application Display Templates, Mobile Device Families (previously known as Mobile Device Rules) and more.

Each of these sections has a direct link from the Dockbar, from within a new menu called "Admin":

This is the result of clicking "Content":

Here are some important things to notice from this screenshot:

  1. This UI is actually pretty similar to the old Control Panel, with a left menu and a main area. Although it only has administration tools associated with the current site.
  2. The name of the site along is shown in the dockbar and to its left there is a link to go back to the site.
  3. The down arrow next to the name provides access to a menu with a list of other sites that the current user can administer. This will be specially useful when the current site displays shared content (a new feature in 6.2) from parent sites or other sites managed by the administrator, as well as global.
  4. The list of site administration tools in the left menu is searchable with instant search (aka search as you type)
  5. When going to a section the user is shown the first portlet within that section. In this case it's Web Content, which will be in many sites one of the most commonly accessed portlets.
  6. The left menu acts as an accordion, That means that only one section can be open at a time. This has been done to reduce the size of the menu, which could otherwise create circumstances such as display the current tool below the visible screen area.


I'm going to finish here the first part of the post. I would love to hear your feedback about anything I've shared and I'll be happen to answer any questions.

In the second part I'll go through other key decisions, such as the reorganization of the portlets left in the control panel, the efforts to reduce the number of pop-ups or how we have kept backwards compatibility for developers. I will also descrived other changes that are still under consideration and waiting for user feedback as well as the results from UX testing.

Update (Aug 14th): I've just published the second part of this blog post.

Liferay's Architecture: Caching (Part 1)

Company Blogs 21 gennaio 2013 Da Jorge Ferrer Staff

Here I am again with another in the series about Liferay's architecture. If you haven't read them yet, the four previous entries covered: Overview, Services Layer, Web Services and Service Builder.

This time I'm going to cover a very important concept: caching. In today's web, it's impossible for a web application to provide even good enough performance in the web unless it has a well designed caching system. So what I'm going to cover here is not only useful to understand Liferay's architecture better but might also be beneficial for anyone writting Java web applications, specially if they are large.

Liferay is known to provide very good performance (check the Performance Whitepaper in the whitepapers section of this website for details) and its caching system is a key factor in achieving that performance. This caching system spans through all three layers. The following diagram shows the main caching components in each layer:

Let's cover each of them one by one, starting with the lower layer.

At the persistance layer Liferay relies on Hibernate to do most of its database access. Hibernate has two cache layers called Level 1 (L1) and Level 2 (L2). Level 1 is used to cache objects retrieved from the database within the current datababase session. In the case of Liferay a session is tied to an invocation to a service layer. So when the frontend layer (or a web service) invokes a service a db session is opened and reused until the service method returns. All operations performed until that point will share the L1 cache so the same object won't be retrieved twice from the database.

Hibernate's cache Level 2 is able to span across database sessions and stores database objects (Entity Cache) and results of queries (Query Cache). For example if any logic retrieves from the database all users that belong to a certain organization, the result will be stored in the cache. Note that what is really stored is the list of "references" to the actual objects which are stored in the Entity Cache. This is done to ensure that there aren't several copies of the same object in the cache.

Besides using Hibernate, Liferay's code also performs some complex database queries directly (although reusing the database conneciton). For these queries Liferay has its own Entity and Query cache. In fact thanks to the work of Shuyang these two caches are extremely efficient and as a result, for Liferay 6.2, we have decided to disable Hibernate's level 2 cache by default leaving Liferay's Query cache as responsible for that task to improve performance.

One final important aspect is that all of these caches use an underlying cache provider to manage the objects in memory. By default Liferay uses ehcache to do that, but it is also possible to change the caching provider through  The configuration is done within hibernate-clustered.xml which defines  and configures several cache areas.

Finetunning these configuration files is a very important task for any high-profile site. But don't try to do it based on guesses. You should always do it while running a performance test suite that can help you find bottlenecks and verify changes in the configuration.

Since I want to try and keep these blog entries shorter and more frequent, I'm dividing it in two parts. In the next one I'll cover the caching mechanisms of the services and the frontend layer.

Liferay's Architecture: Service Builder

Company Blogs 3 gennaio 2013 Da Jorge Ferrer Staff

One of Liferay's "secret" ingredients, specially with regards to its architecture, is Service Builder. This is the tool that glues together all of Liferay's layers and that hides the complexities of using Spring or Hibernate under the hood.

Service Builder was originally built when Liferay used EJBs for everything (in fact it's name back then was EJBBuilder). EJBs were actually built around several very sound architectural patterns, but unfortunately the implementation was not as good. One significant pain for developers using EJBs was that it was necessary to write many XML files and Java classes to do even the simplest thing. So Brian Chan, Liferay's founder, who is known for being super efficient, decided to build a tool to do it for him. When Hibernate came around Brian was able to use Service Builder to switch from Entity EJB's to Hibernate literally over a weekend (I was blown away back then). Later on Service Builder also allowed switching from Service EJBs to Spring, gaining a lot of flexibility.

Service Builder has grown a lot since then. I used to be very skeptic with source code generation until I got to know Service Biulder better. It doesn't pretend to be a generic code generation tool, but rather to meet the needs of Liferay's developers (including plugin developers). It is also very opinionated, in the sense that it doesn't offer many options, just the ones we think fit better in Liferay's context. Because of that it might not be a tool for everybody but in exchange it provides a great degree of consistency to anything develped with it and is easier to learn. The general idea is simple, it just takes an XML file as an input (usually called service.xml) and generates the necessary persistance, service layer, web services, ... infrastructure around it. Check Liferay's Developer's Guide for info on how to use it.

One key breakthrough in the evolution of Service Builder actually happened with a contribution (can't remember the name of the contributor, does anyone know?). Previously, all of the code that was going to be generated was included as Strings within Java code and a community member took the time to move all of it to Freemarker templates. That has made the evolution and maintainence of Service Builder so much better that I don't have words to thank him :)

Right now, for every file that Service Builder will generate there is a Freemarker (.ftl) file associated with it. For example, do you want to find out how a * file is generated, you just have to look at service_impl.ftl within com/liferay/portal/tools/servicebuilder/dependencies 

That's it for now, hope you liked the entry and see you soon for the next one.

Liferay's Architecture: Web services

Company Blogs 26 dicembre 2012 Da Jorge Ferrer Staff

It's taken a little longer than planned due to Liferay's annual company retreat and the engineering retreat we did along with it, but here I am with the third entry in the Liferay's Architecture blog series. I also plan to write a fourth one and schedule it for publication next week while I'm on vacation. 

My last entry explored how Liferay's code is organized around the concept of services which are used from the frontend (portlets, servlets, ...) but that can also be used by third party or custom plugins using the available Java API. The goal of this entry is to show how the remote services layer is also exposed through several web services protocol for remote consumption.

This layer is built automatically by that wonderful tool called Service Builder based on the remote service interface and annotations left in the implementation by its developers. One of the benefits of automatic generation is that it is easy to support many protocols with little extra effort. However I'm only going to mention the two most significant and used protocols:

  • JSON Web Services: This is a new way of accessing Liferay's web services that was added in 6.1 thanks to the lead of Igor Spasic. It provides a lightweight RPC-based protocol that uses JSON as the data exchange format. This protocol is specially useful when invoking the services from JavaScript (including from the browser) or other non-Java languages. It can also be useful for mobile apps. In fact Liferay Sync Mobile App (guide) for iOS and Android uses this protocol to communicate with Liferay. One very nice and not so widely known feature of JSON Web Services is that it comes with an API browser included. You can access it by going to the URL http://your-host-name/api/jsonws (don't forget to secure it for production). For more information check the JSON Web Services chapter in the Developer's Guide.
  • SOAP: The good old XML-based protocol that has declined in popularity lately but is here to stay. One of the main benefits of SOAP is the amount of tooling available as well as the out of the box integration offered by some software packages. If you need to use SOAP to communicate with Liferay (and it still happens often), it is supported for you. For those curious about the implementation we use Apache Axis 1.4 to handle the protocol aspects. We don't use Apache Axis 2 for a variety of reasons including the fact that it is distributed as many JARs, some of which are already provided by some app servers out of the box which makes support across all app servers quite harder.  For more information check the SOAP Web Services chapter in the Developer's Guide.

One last important aspect you should know is that all web services in Liferay will be invoked using Liferay's permission system. The client applications need to provide the credentials of the user they want to execute the methods as. The simplest option to do it is using HTTP Basic Authentication. That means that if you are accessing web service through an unsafe network (which will be most probably the case) you should use HTTPS to avoid sending the passwords on clear. An alternative coming in 6.2 (which is much nicer in many ways) is to use the OAuth protocol.

That's it for now. I'll use this opportunity to wish you all a Merry Christmas (or for those who don't celebrate Christmas, Happy Holidays! :)) 

Liferay's Architecture: The services layer

Company Blogs 22 novembre 2012 Da Jorge Ferrer Staff

Here I am again for a second entry on the series of Liferay Architecture. This time I'm going to talk a bit more about the services layer of Liferay. As can be seen in the architecture diagram with which I started this series, the services layer is at the core of Liferay Portal:

The Services layer contains the great majority of the business logic for the portal platform and all of the portlets included out of the box. The services are organized in two sets:

  • Portal services (com.liferay.portal.service): contains the services for the portal level entities. A simple trick to identify them is to look at the "Portal" section of the Control Panel menu.
  • Portlet services (com.liferay.portlet.*.service): contains the services used by the different portlets in Liferay. There are also some packages that are not really associated to one portlet (or to more that one), so the word portlet here is being abused a little bit. What matters is that all the services that are no part of the core portal platform are properly organized and componentized.

One very specific aspect of the services layer is that it is divided in two sub-layers:

  1. Local Services (<Entity> this are the ones that that contain the business logic and communicate with the persistance layer.
  2. Remote Services (<Entity> the main goal is to perform security checks before invoking the equivalent method in the local service. In some cases the remote services are also responsible for converting the Java objects returned by the local services layer to other formats. For example, the RSS generation for portlets that support it is done in remote services.

I'm going to finish the entry with some further facts and patterns of Liferay's services layer. The first are more well known but some aren't:

  1. Each persisted entity has an associated service. For example, the User entity has UserService, DLFileEntry (the entity used to store documents of Documents & Media) has the DLFileEntryService.
  2. The services methods are executed in a transaction. That means that if your database supports it (and most do) if there is an error in the middle of the execution of a service method (or in any other method invoked by it), all the previous operations will be undone (rolled back) automatically for you. Liferay implements this under the hood using Spring's transations mechanisms.
  3. The persistance layer is always accessed from local services. You should never access it directly unless you really know what you are doing and you are able to handle transactions manually from the invoking code.
  4. The local services are very strict with the return types of its methods. The return type should be one of the following:
    1. void
    2. <Entity>
    3. List<Entity>
    4. primitive type (this is not used often)

That's it for this second entry. I'm looking forward for your feedback. I'd love to know what topics are more interesting to you so that I can keep them into account for next entries.

Update Nov 29th: Added primitive type as a 4th return type. Thanks David for the note about it.

Risultati 1 - 20 su 65.
Items 20
di 4