I've been presenting and demoing Liferay Cloud Services at Symposiums, events and customer visits for quite some time now, and most of those presentations had one thing in common: before I presented the product, people thought it was about a hosted or managed platform. “No, no, no. These are *Cloud-based services*, meaning the services we are offering RESIDE in the cloud...not that YOUR server resides in the cloud”...man, I have explained it so many times!

If you launch a product and you constantly need to explain what it does, because the name is confusing...then you have a problem! So we have been thinking about this, and we have finally decided to change the product name to one that is better prepared for the future and is less confusing for our customers. So the goal of this blog post is to say bye-bye to Liferay Cloud Services and …

Welcome to Liferay Connected Services!

Why did we decide to call it that? Well...it’s quite straightforward: we are offering added-value services and the only thing our customers need to unleash the power of this product is just connect it to their on-premise or cloud-based portals.

For those who still don’t know what these services are, Liferay Connected Services are an online platform that offers a set of tools and services that will help our customers succeed on their Liferay projects.

The services that we are currently offering are the following:

Page, portlet and server metrics

Cache insights

Fix pack and security updates management

And yes, all for free! These are the services we are offering as of today, but we are planning to release many many more in the future. We want YOU to have a 360º view of your portal

“But...is that all you have for us on this update?”

Not at all! We have more good news! Since we launched the first beta, our users asked for an email notifications system that would warn them when something’s wrong with their servers… and here is the first version of the email notifications service!

Now you can configure for each project, environment or server if you want to receive an email alert when a new LCS client, fix pack or patching tool version is available, when a server goes down, when monitoring is unavailable or the patching tool is not correctly functioning. Helpful, right? :)

What's next? If you want to try these services, you can do so in just three simple steps:

Based on market research and community feedback, we’ve seen that more and more companies are using location-based information to make important decisions. Also usage of geolocation tools as a way to show map-based information to the end user is growing.

It is increasingly important to know where the information is being generated, showing maps of your entities, understanding where your users are filling in your forms from, or where they are uploading documents from. Showing maps with your offices’ location, training courses, etc is the norm on many IT projects nowadays.

This is why one of the Epics we are working for Liferay 7.0 is adding the geolocation layer to (y)our platform. The goal of this article is to explain the use cases we are covering with our current implementation in order to get your feedback, thoughts and ideas NOW we are in development phase (as opposed to after the official release, when it’ll be too late to quickly iterate).

#1: Geolocate documents, web contents and ddl records

The first feature the engineering team has been working on is adding the geolocation field to DDMStructures. This means that now you can add an additional field to your web content structures, document types (therefore images) and DDL records. Every time a user creates one of those assets, he’ll be able to define “where” it is.

The geolocation system can work in two different ways: first by letting the system know where you are using HTML5 (specially useful on mobile devices) or second by the user giving the system directions to a concrete place

[Note that we are currently implementing DDMStructure based custom fields, so when that is ready, this geolocation field will be available not only to assets but to all entities in the portal!]

#2: Show maps of assets

After the content is geolocalized by your users, the next step is to show that content on a map. For that, we’ve added map support to Liferay. We have created a reusable taglib that you can use in your portlets, ADTs and templates. Out of the box we have an ADT called “Maps” that can be used on your Asset Publisher: once you choose it, a map view will be loaded and you’ll see your geolocalized assets on it. Obviously, if you define filters in that Asset Publisher, they’ll be respected. Cool, isn’t it? ;)

#3: Support for different map providers

We’ve also thought on those who want to have the power to decide which map provider to use. We’ve made it configurable, and out of the box we offer Google Maps and Open Street Maps support, but of course, it is extensible, so you can create your own integration for additional map providers.

Conclusions

By this time you already know that we LOVEbeta testers and feedback and that is why we share all this info with you. Before we continue implementing more user stories related to geolocation, we wanted to ask you: what do you think about these features? Do you think they’ll be useful for your projects? Are you thinking in a user case we are not covering? How could we improve it to better suit your needs?

As I promised on my previous post (Liferay 6.2 new mobile features (pt. 1)), here’s the follow-up blog entry with a description of more features and improvements related to mobile we are going to release as part of Liferay Portal 6.2.

On this article I’m going to talk about the reuse of native mobile components, improved device detection capabilities and using sites hierarchies for building mobile targeted sites. And there are still more new mobile tools and capabilities to talk about in a third blog post (namely, the new Mobile SDK and the new version of Liferay Sync Mobile).

Reuse of native mobile components

One of the goals for this version was to be able to create tools that provide a great user experience. We wanted our users to feel familiar with Liferay, even if it is the first time they’re using it, even if they are not using a laptop.

There are multiple ways to achieve this, but possibly one of the best ways when talking about mobile is the reuse of native components. It is not always possible to reuse them, but there are several places in the portal where these components provide a great experience.

One of the great benefits of this approach is that when the users update the operating system on their mobile devices, these components will also be upgraded. For example, with the latest update to iOS 7, our calendar component is upgraded too, making it look consistent with the rest of iOS apps.

I’ll mention a couple of them so that you can better see what we’ve done (screenshots from iPad and Android devices):

Native calendar component:

Native dropdown and radio button menus:

Documents and images upload:

Improved Device Detection capabilities

One of the most used approaches when planning a mobile web strategy is the device targeted website. Basically it consist in a subsite or an extension of the desktop website, which is optimized for certain device. You might have seen this on sites that have a normal site url on desktop (www.mysite.com) and a mobile url for smartphones (m.mysite.com).

Since we launched Liferay Portal 6.1 we have had mobile device detection capabilities, via WURFL integration (you can read more about it in the User Guide), but on the new version there are several improvements for companies using this mobile strategy. These improvements include a UX revamp, adding additional device classification criteria and sites hierarchies, which is not a mobile-specific feature, but it becomes really useful in order to implement this strategy.

Name changes and help messages: it might seem superfluous, but after gathering user feedback we detected there were a bunch of misconceptions regarding mobile device detection rules, so we invested on fixing it.

and added a help message to the creation form explaining what they are for:

We did the same for rules: based on user feedback we renamed them to “classification rules” and also added a help message:

And then, action abstracts are brought to the rules screen, so that you can see them at first glance:

And finally, for those pixel perfectionists that have been asking for it during the last couple of years, we have added screen size and screen resolution detection support (thanks, Milen! Cool improvement! :D):

Taking advantage of sites hierarchy for dedicated sites

When a company plan to invest in the dedicated website mobile strategy, one of the most common issues that arise is the content sharing. Having an optimized separate website for, let’s say, you company’s iPad users is great, but how can you reuse all the content generated on the desktop site and yet have the flexibility to manage device specific content? Now we have site hierarchies this is super easy to achieve! Let’s see an example:

Let’s create a website for a company, and then let’s create to child sites, one of android devices and another one for iPads

Now let’s create the device families and rules in the parent (desktop) site. Note: you could create the rules in the global site and they’ll be available on all your sites.

And finally the actions:

With this we are ready to start creating our three versions of the site, and depending on the device accessing our website, the user will see an appropriate version for his device.

The benefit of using site hierarchies is that child sites can access their parent’s content (if they are given the correct permissions) using the asset publisher, so the door to reusing content is opened. On my example, parent and children sites share a common banner and then each one add more content specific to their audience.

First let’s configure an asset publisher to get the parent site’s banner:

And then you can see the result of this (SIMPLE!) example. First, a desktop site:

An android version of this site, reusing the banner but adding more device-specific content

and finally the iPad site, also reusing the banner but adding specific content for iPad users:

Simple and powerful!

With this set of features we are releasing on Liferay Portal 6.2, Liferay is well on it's way to being the mobile experiences delivery platform we have envisioned for many years. I hope you like this version and share your experiences with us so that we can continue improving release after release. For you.

One of the most important and remarkable improvements of the new version of Liferay Portal are the new mobile capabilities that come out of the box.

We will be presenting these features all around the globe via symposiums and roadshows, but for those of you who can’t wait, or can’t attend one of our events, here’s a preview before the official launch of the product.

Among the mobile improvements there are the following: mobile device preview, usage of responsive modules, usage of native components, UX improvements on mobile device rules, the usage of site hierarchies to build mobile websites, the new Mobile SDK (beta coming soon!) and a new version of Liferay Sync Mobile.

As you can imagine, it is impossible to write a blog entry that covers all these new features, so I’ll focus on the first two of them: mobile device preview and the responsive modules that comes out of the box with this new version.

Mobile Device Preview

With the clear intention to bring website admins’ attention to the mobile world, we decided to offer a mobile device preview menu a click away from all your site’s pages:

On this menu we provide a preview of your page as it is going to be seen by users with devices of that screen size. We added most common configurations, but offered the possibility to configure any screen size you might want to test.

Using the device preview we want to give our users the possibility to feel the same experience as the visitors of your site, despite the device they are using to reach your content.

Responsiveness out of the box

Thanks to AlloyUI and Twitter Bootstrap we can offer a high level of responsiveness out of the box. For example, all page layouts are responsive and we have made a mobile optimized version of many of our UI modules so that the navigation experience using mobile devices is optimal.

Here are a couple of examples of mobile-optimized modules, for you to better understand the kind of enhancements we have implemented:

The new dock bar, which looks like this on the desktop

becomes simplified on mobile devices

Search, links and view mode buttons that appear on many portlet’s headers, look like this on the desktop:

and they become like this on mobile devices:

The toolbars that appear on the WYSIWYG editor are like this on desktop:

but for mobile device we have create a light version, better suited to the usage on the go. It becomes something like this:

All buttons in the portal become finger friendly, are much bigger so that they are easy to tap with your fingertips:

The pages navigation, which usually looks like this on the desktop:

is merged into a single button, so that it frees screen space and on mobile devices it looks like this:

And, well these are just a bunch of examples, but there are many more all around the product...and many more still coming!

I'd like to thank the UI team, who has invested a lot of time an effort to make responsiveness and mobile a reality on this version: Bruno, Eduardo, Chema, Iliyan, Nate, Patrick, Mark, Jonathan (and more I might forget): thanks, UI team!

We are looking forward to start receiving your feedback so that we can continue improving and delivering the best product possible for you, our users and community.

For the last few weeks I have been working on a new framework for Liferay Portal. We have decided to call it "Application Display Templates Framework" ("ADT Framework" for family and friends :D), and it is basically the application of our templating system to the way we see information in our applications in Liferay Portal.

The ADT Framework will allow portal admins to define via Velocity templates how to show the information on each portlet. Imagine you want to show up your blog entries horizontally, or you want to list your assets in the asset publisher in different sizes depending on where they are going to be shown: now you can do it by using custom Application Display Templates! Cool, right? :)

For the moment I have applied it to the Asset Publisher and the Blogs portlet, but I plan to apply it to Wiki, Navigation, Site Map and Tags/Categories Navigation.

How can you use it? There's a new application in the control panel called "Application Display Templates" (it's in the "Site" section) where you can add and manage the ADTs for the different apps in Liferay, and appart from that, on each on of the portlets that support ADTs (blogs and asset publisher for the moment), in the configuration screen you will be able to choose your ADTs, or the global ADTs (if available).

Appart from this, you'll be able to plug your custom plugins into the ADT framework, just by implementing the interface PortletDisplayTemplateHandler and declaring your implementing class in liferay-portlet.xml (in "portlet-display-template-handler")

How will the ADTs can look like? They will be just normal velocity templates, like the ones you use for the web content or the dynamic data lists. Additionally, there are a set of variables that have been made available for the templates (like $entries, which is the list of entries the user can see at a given moment) so that you can access all the information you need. There are a few samples made available for you in the asset publisher.

We have many improvements in mind that are related to this feature, but before going on I wanted to share this with you.

I write this blog entry for two reasons: the first one is to have the community updated on new features we the core engineering team is working on for the next version, and the second reason is to ask for your feedback and comments.

Today I want to summon the Liferay Bugsquad and the rest of community members: I'd be delighted if you could test this new feature in current trunk, and I'd love to receive your feedback, the templates that you may build, your ideas, your complains or pain points, so that we can improve it asap.

Remember we do Liferay Portal for you: this is the kind of moments when you can have a real impact in the evolution of YOUR project.

Thanks in advance, and I hope you like it

Juan Fernández

[UPDATE] Thanks all for your feedback! We have added the features you asked for and today (a little after Milestone 4) we have implemented Freemarker support and ADT support for Asset Publisher, Blogs, Wiki, Documents and Media, Site Map, Tags Navigation and Categories Navigation... I'm sure you'll love this tool to create new awesome sites!

Many of you know a lot and do an extensive use of the Asset Framework, the framework within Liferay Portal that "provides a set of functionalities that are common to several different content types".

In many projects we find that developers need to extend the behaviour of the AssetRendererFactories to fit their needs, and, even it is not that hard, it takes a while to think on the best and cleaner way to achieve this.

In a recent forum post, a user asked how to modify the UserAssetRendererFactory and I decided to write down the steps in a wiki article to share it with the rest of the community.

Here's the link, but for the most impatients, here are the steps to do:

In a recent project I had to add these portlets ("My Workflow Tasks" and "My Submissions") to a normal user page. By default they are shown in the control panel, but depending on your project needs you may want to use them elsewhere. Here are the steps you need to achieve this easily.

Basically you need three things:

Remove them from the control panel

Add them to the "Add Applications" menu

Add "ADD_TO_PAGE" permissions

To do this you need an ext plugin (which you can create in the liferay plugins sdk via <<create my-ext "my ext">> command)

Once you have your ext plugin ready in your plugins sdk, go to your-ext/docroot/WEB-INF/ext-web/docroot/WEB-INF

in your-ext/docroot/WEB-INF/ext-web/docroot/WEB-INF/liferay-portlet-ext.xml add this (this is the original content minus the control panel classes configuration)

Today, while I was reviewing bug and improvement requests tickets from the community members, I saw a ticket created by Sven Werlen from Savoir-faire Linux, a canadian company.

They needed the asset publisher to be able to access and publish assets from all their communities and organizations and they've developed a hook that does this so that they can choose the scope in a wider way, and, here's the magic of the Liferay open source community: they have decided to share it with all the community so they have published their hook in the community plugins repository (Link here: http://www.liferay.com/downloads/liferay-portal/community-plugins/-/software_catalog/products/6268657)

This is the kind of changes that we may not be interested in adding to the core but some of you may be interested in, and that's perfect for the community to share. I think this is great, to see that there are some companies and individual developers that are willing to share their expertise and experience with the rest of the community, and this is the starting point of the market place we are planning: a place where we can all share our plugins.

Things like this make me proud of working in an open source company like Liferay.

What are sanitizers? Sanitizers are a filtering element that "sanitize" web content (usually HTML or javascript code) so that it doesn't contain unappropiate content like javascript malicious code or swearwords, for example.

The portal.properties file has been updated with this entry:

sanitizer.impl=com.liferay.portal.sanitizer.DummySanitizerImpl

so that we can use our custom sanitizer.

For the moment it's being used in Blogs portlet out-of-the-box, just before entering the contents in the database, but this can be applied to whatever entity we need using plugins. For example you can use it in a Model Wrapper Hook for Wiki pages or a Model Wrapper Hook for web content.

There's already an antisamy hook in plugins repository that is ready to be used and it can be used as an starting point for you developers that are interested in implementing your custom sanitizers. (Read more about the antisamy project here)

To use this in core entities the best way is to use model wrapper hooks (read more about this kind of plugins here), so that you include this filtering before creating the entity and its related objects (like tags, categories and so on)

One of the many great improvements of Liferay 6 is the workflow system, as many of you already know. We have been working hard on it and we have developed lots of new functionallities that we're sure you'll love.

In this blog post I'll implement a use case so that you can see workflow in action, and by the way, I announce that in the wiki we've created a series of articles that describe the workflow portlets and what are they for. You can read them by clicking in this wiki link: http://www.liferay.com/es/community/wiki/-/wiki/Main/Workflow

Intro:

In this example we will create the following users:

Reader: this is a simple user that is a member of the community "My Use Case Community"

Content Writer: this is the content writer of the community. He's able to create web content

Content Reviewer: this is the person in charge of controling the content that is going to be published. He can decide if the web content is correct or not.

Content Publicator: this is the member of the community that publishes content, add new applications to the community and so on.

Portal Admin: super user that will prepare the environment of this use case

Configure the environment:

With the portal admin, I create "My Use Case Community" and the four users, which I assign to the community as new members.

Assign roles and permissions:

Assign the "Community Content Reviewer" role (which is an autogenerated role from the workflow definition) to the user "Content Reviewer", so that he can review content

Assign the "Community Administrator" role to "Content Publicator" so that he can manage everything in the community

Create a new community role called "Content Writer" and assign it to "Content Writer". This role would have web content's permissions (I don't usually give him "delete" and "permission" permissions, but that's up to you) and access in control panel, so that he can create web content from the control panel (this is not strictly necessary, as he can create web content from the asset publisher, for example)

Login as the "Content Writer", go to the control panel and create a new web content. Notice that the available buttons are "Save as draft" and "Submit for publication", so that the user knows that he can't publish directly (by the way this is a good way to know that the workflow engine is correctly applied to your community). Click "Submit for publication".

In this moment, the workflow engine starts. The user can see that the content's status is "pending" and he can't modify the content till it's reviewed.From this moment on, the content writer can follow the process in the "My Submissions" portlet. There he can see the internal workflow status and if he realizes (for example) that he wants to modify something in the content, he can withdraw the submission.

2.- Reviewing the content

It's time for the "Content Reviewer" to start working.The main part of the reviewer work is going to be done in the "My Workflow Tasks" portlet, so let's go there. In the "Assigned to my roles" view, you'd see the pending tasks and you can assign the task to another user or yourself.

I assign it to myself

In the detail view of the task, you can view and edit the content, read the recent activity of the task, view the status and change its status (in this case approve or reject, but this would depend on the workflow definition)

In this moment, there are two possibilities: a) The reviewer rejects the content: he writes the reason in a popup and the content goes back to the writer, so that he can edit/fix/improve it b) The reviewer approves the content: he (maybe after editing the content so that it fits the portal's rules) approve the content and the content's status is updated to "approved".

3.- Publish the content

The user "Content Publicator", that handles the portlets and has publishing rights, now can go to the community pages and add a web content display portlet with the new content in it

4.- Access the content

The user "Reader" (who, remember, has no special permissions, but is a community member) is now able to view the new web content

when you start developing in Liferay you notice that there are many modules and libraries in its core, but there are not accessible from everywhere.

I recently found a problem developing an improvement for the workflow system (see http://issues.liferay.com/browse/LPS-8821), where I needed to use a class that I couldn't access... and I realized that I needed to know which concrete classes were reachable from where I was.

I have done a little research and I've written a wiki article explaining this, and I have created a diagram to make it easier to understand:

I hope it'll be useful for you, developers!

Regards

Juan Fernández

[IMPORTANT UPDATE: This has recently changed for the current Liferay version - 6.0.2. portal-service and portal-kernel have been merged, so that it's much easier now to develop. See http://issues.liferay.com/browse/LPS-9370 for further information]

Last week I created the sample expando hook, a simple example to show how easy is to extend portal entities on startup without using the UI.

The main goal of this work method is to allow Liferay users to extend portal entities from a plugin, so that they don't need to repeat the same action (the creation of new fields for their entities) in every installation they do.

You can find it ready to use in the plugins' hooks svn (http://svn.liferay.com/browse/plugins/trunk/hooks)

I have based this development in this Ray's blog entry (http://www.liferay.com/web/raymond.auge/blog/-/blogs/adding-expandos-from-a-startup-hook) and here's the explaination so that you can adapt it to your concrete use case:

In portal.properties you declare your class so that it is launched on startup:

Liferay's objects are being encapsulated into assets (documents, web contents, blog entries are being encapsulated in the new asset concept) and it allows the portal objects to be treated in a consistent way.

There are several portlets that are designed to work with this kind of objects and you may be interested in doing this with your custom objects.

I have been working with the Calendar Events to add this functionallity for Liferay 6.0, and this blog entry is the result of that experience. This will allow us to tag and categorize calendar events, so that we can search them much easier, create them not only from the calendar but from the asset publisher and track the creation from several places.

If you have created a custom object (for example "school_teacher") and you want to convert it into an asset, these are the steps to follow:

In YourObjectLocalServiceImpl.java, in every CRUD (create, read, update and delete) method, add a call to its respective asset method through the assetEntryLocalService object

For the last few weeks I've been working in a new WYSIWYG editor for Liferay 6. It's the new version of FCKEditor, called CKEditor.

Which are the improvements of the new version? The main improve is accessibility: it is WAI-AA and WCAG 1.0 compliant. It implements advanced screen readerssupport, it's fully keyboard navigable, it has natural TAB key usage with tabindex support and operating system High Contrast support.

It is also compatible with most Internet browsers and operating systems, including Internet Explorer 6+, Firefox 2+, Safari 3+, Google Chrome and Opera 9.5+:

this week I have been working in the Asset Importer, a portlet that reads a file (odt for the moment) and converts it into a web content so that you can publish your documents an your website.

We will use this to publish Liferay documentation in Liferay.com very soon

Developing this portlet I had to use for the first time a wrapper plugin. This is a variation of the hook plugin that allows you to extend core functionallity by creating a wrapper for a concrete core class... and there's no documentation at all, so that's why I'm writing this! :)

In my case I needed to do a few things everytime the user deletes a journal article, so here you have how I did it:

How to use Liferay's Wrapper Plugins

Note: I'll use a example that extends JournalArticle deletion to be more illustrative.

The steps to do to use this functionallity are the following:

Create a file called liferay-hook.xml with the following content and place it docroot/WEB-INF:

It's already been a month since I started working in the Liferay team, in the spanish office and I wanted to write a presentation post.

When I was part of the community I sometimes missed knowing what was going on in the Liferay team: "What are they doing at this moment?", so I want my blog to be somehow that answer (at least on what concerns my work!)

These last weeks I have been involved in CKEditor integration for Liferay 6 and I've been working along with Jorge Ferrer in a new Asset Importer Portlet and the new Asset Link concept: I'm sure you'll like this!

I'm interested in the community and I'm working to make the best of it. I'd like to improve communication and participation, improve documentation, organization, promote feedback in the forums, etc.

I'm also focusing my interest in cloud computing, and soon I'll be writing about this and how can Liferay approach Cloud Computing (or not! :D)