Data upgrade finalized for all bundled applications: You can now start testing the upgrades from your Liferay installations to Liferay 7. We really need your help here since there are so many different variations to consider. With your help it will be much faster to make upgrades rock solid. Please try it out and notify any issues through our Community Expedition forums.

Bundled plugins/modules included: our final bundles come with many plugins/modules included out of the box. For beta, we are already including those that we plan to release in the final bundle. This is also an opportunity for you to check them out and let us know if you think anyone should be added or removed (since Liferay 7 is so modular, adding or removing is much more granular than before).

Bundle with Tomcat and JBoss EAP supported: This is a slight variation from our criteria. We have switched from Wildfly to JBoss EAP, although Wildfly will still be supported in our final release.

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

Improvements

This release also has tons of bugs solved and quite a few improvements. These improvements included applying more lexicon based designs, finishing some features and doing several UX improvements based on our own tests and the feedback from our explorers.

One significant UX change that I would like to highlight is the design changes in the Product Menu. As you can see in the picture below we have decided to switch from a tabs for the top level to an accordeon:

The main reasons for this change are:

It works much better for users with fewer permissions (which are the majority) and it scales better for those with more permissions.

It avoids navigation within the menu, which proved to be confusing to many users (who kept asking "What's this back arrow here?"

It provides more space to show the user name, which allowed removing the area at the bottom with the (duplicated) user name.

Attempts to solve the situation where users were asking "How do I go back?" after going to a personal or control panel application. We identified that in those cases the users wanted to go back to the site they were at, so now that site is always visible in the menu and there is a link to go to the site if desired.

This menu also has an integrated pages tree, which allows for faster navigation through the site hierarchy for administrators:

Note: We are still trying out different ways to add pages. The one in this release has proved to have some issues, so it will still change before the final release.

You probably have not had time to digest Alpha 3 yet, but here we are again with a new preliminary release: Liferay 7 Alpha 4 is out! This release fixes 82 bugs resolved since Alpha 3 and adds 31 small improvements: More portlets getting Lexicon-based designs (including Site Memberships, this time for real), several functional improvements to Forms, notifications in the product menu, etc.

And if you were wondering how did this happen so soon, the good news is that we have entered the final phase of Liferay 7's development and now we will be making weekly releases. Every Friday you will have a new release uploaded to Sourceforge showcasing our progress towards the final release (with some exceptions due to the holiday season).

Since we are going to be releasing so often I won't be posting blog entries for every release. In fact they would be quite boring since most, if not all, changes from now on will be related to quality improvements, either directly (such bug fixes) or indirectly (such as ensuring technical and UX consistency across the product, for example by applying Lexicon-based designs to some remaining apps). I still plan to write blog entries whenever there is something relevant to say, such as reaching a milestone or presenting certain specific improvements. Also, if you still want to be notified of all releases follow our Liferay Engineering twitter account to be the first to know about it.

If you want to help us keep improving the release to have it out the door sooner get Liferay 7 Alpha 4 now from Sourceforge, and join the Community Expedition. (BTW, you will see an error in the logs that can be safely ignored. It's known and fixed already but we decided to not delay the release because of it)

This Friday there will be a new release with a redesigned product menu. We are also working hard to solve some issues with Sybase related to code necessary for the upgrades and if we can get it all to work... we will have our first beta! :)

Enjoy!

引用通告 URL:

相关资源:

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

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

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

Highlighted improvements

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

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

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

The following applications were also fully finished:

Page Templates

Site Templates

Tags

Categories

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

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

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

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

Pretty cool, right?

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

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

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

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

Some other additional improvements of the Forms application are:

Ability to view details for an specific form entry

Added support for adding captcha challenges to forms

Ability to configure a redirect URL after submission

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

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

Release criteria for Alpha, Beta and Release Candidates

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

In order to release Alphas, the criteria is:

All major features finished

60% pass rate for our automated priority 5 functional tests

Bundle with Tomcat available

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

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

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

Bundle with Tomcat and Wildfly available

Official languages translated to at least 70% of all keys

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

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

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

End to end testing (including Marketplace installations and licensing)

Official languages translated to at least 99%

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

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

相关资源:

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:

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.

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.

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.

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:

Web content

Forms

Dynamic data list

Tags

Categories

Recycle Bin

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

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

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.

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:

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.

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.

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:

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.

Recap

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.

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?

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.

WCM

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.

More

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.

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.

Modularization

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

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.

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:

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

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.

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).

Staging

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.

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.

Geolocation

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

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

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 :)

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.

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:

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.

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 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-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 Medium.com 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.

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 ;)

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 portal.properties and all extensions of liferay-portlet.xml as OSGi components.

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: https://issues.liferay.com/secure/StructureBoard.jspa?s=235 (Thanks Esther for setting this up!)

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:

Themes built for Liferay can be based on Bootstrap themes. And therearequite a few of them.

Content authors can use bootstrap mark-up and styles to create beautifl looking advanced content that looks nice and is consistent with the rest of the UI.

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:

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:

<divclass="row-fluid">

<divclass="span4">...</div>

<divclass="span8">...</div>

</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:

From a Liferay page, click add > content and then create new (Basic) Web Content.

Give it a title and click the "Source" button in the editor.

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)

Paste the HTML inside the editor.

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.

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.

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 liferay.com 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:

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

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'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.

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!! :)

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?

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 liferay.com.

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:

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.

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.

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.

The list of site administration tools in the left menu is searchable with instant search (aka search as you type)

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.

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.

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 portal.properties. 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.