ACA Blog

ACA Blog

February 2020
« Jan    


User-specific versus shared portlet preferences – part 1

Peter MesottenPeter Mesotten

This article is the first in a series of 2 posts on how personalization can be achieved in a portal project. Moreover, the concept of sharing personalized settings between users is explained and how this behavior can be changed in Liferay.


One of the most important features of a portal is personalization, or the ability for users to change the behavior, content or visualization of portlets. In most projects we’ve done, customers are very skeptical about personalization. For those customers, enabling personalization equals enabling users to mess things up and call for support afterwards. We believe however that personalization, if implemented the right way, creates a dynamic experience that will increase the usage and ultimately extend the lifetime of the portal.

Preferences scopes

The Portlet 2.0 specification (JSR-286) enables personalization through the definition of portlet preferences. According to the spec, preferences are simple key-value pairs that are stored for each portlet and for each user. This means that two users who look at the same portlets will see two different versions of it, according to the preferences they have set on those portlets.

Since Liferay implements JSR-286 you would expect Liferay to store preferences on a per-user basis too. This is however not the case. By default, Liferay stores them inside the scope of the site that portlet lives in. This means that all site visitors will get to see the same configuration for a certain portlet instance. Luckily, the scope in which preferences are stored can be changed. For this, we need to update the liferay-portlet.xml.

There are 3 properties that are related to the storage of portlet preferences:

The first configuration parameter is the easiest one to understand. If preferences-company-wide is set to true, the preferences for portlets are stored portal-wide. Every instance of the portlet on every page within every site will have the same preferences. Changing the preferences in one place will change the portlet in all other places. If this parameter is true, the other configuration parameters are ignored.

The other 2 parameters, preferences-unique-per-layout and preferences-owned-by-group, can both be true or false as well. In this case, the combination of these settings will define the scope in which the preferences for portlets are stored.

If we do the math, we end up with 5 options for storing portlet preferences. The implications of those options can best be explained by giving an example.

Example: QuickLinks portlet

Consider a custom portlet that can be configured to show one or more links to internal or external pages, resources or applications. The set of links that should be visible is configured using portlet preferences. In this case, the preferences scope configuration will decide which quick links will be visible for which users.


It is clear that Liferay’s addition to the Portlet 2.0 specification with regard to portlet preferences enables a great amount of. Defining the scope in which preferences should be stored is an important decision that needs to be taken during functional analysis, not during development.

One limitation of this is that it seems impossible to store preferences in multiple scopes at the same time. Indeed, the liferay-portlet.xml configuration is applied to all preferences. Sometimes however, it could be useful to store default preferences on a global level (e.g. portal-wide or site-wide), while allowing end-users to override this global configuration with custom preferences. In case of the QuickLinks portlet, an administrator could provide a default set of quick links that are used if a user has not set his own quick links.

The next part of this series will explain in detail how this can be achieved in a clean, reusable way…