Liferay: A note on Portlet Namespace

Portlet namespace is a unique ID associated to each instance of the portlet provided by the portlet container.

When a team is working on a Liferay project, there are several portlets are created. From my experience, I have seen projects having 150+ portlets. So it’s very difficult to track the client side elements, such as JavaScript function, HTML elements IDs etc., which are being written by several developers. Portlet Namespace is a solution of the same. This tag returns the ID of the portlets which can prefixed with client side elements. This tag returns the ID of the portlet, with instance ID in case of instantiable portlet. Portlet Namespace can be used by several ways, to day we’ll see getting it by tag and PortletResponse object.

Non Instantiable portlet’s ID:
_empiricismportlet_WAR_namespaceportlet_
_{Portlet WAR ID}_WAR_{Portlet ID}_

Instantiable portlet
_empiricismportlet_WAR_namespaceportlet_INSTANCE_rwgp46_
_{Portlet WAR ID}_WAR_{Portlet ID}_INSTANCE_{random ID generated by Liferay}_

Usage of <portlet:namespace />
<portlet:namespace /> gets converted to ID at the time of JSP’s conversion to class.

In JavaScript


So internally the mark-up generated will be as follows:

Usage by PortletResponse

Namespace can be obtained by any of the PortletResponse objects:

1. renderResponse.getNamespace()
2. actionResponse.getNamespace()
3. resourceResponse.getNamespace()

for example, I’ll consider renderResponse object is available on the JSP


To conclude, both the approached are same however <portlet:namespace /> most preferred way. However second one is needed when you are in controller class, utility methods or TLDs.

That’s all for today. Thanks for reading and have a nice day.

Liferay: Understanding theme:defineObjects

In the previous post, we have gone through the implicit objects provided by <portlet:defineObjects/>. In the continuation, today we will go through the implicit objects provided by <theme:defineObjects />.

Similar to <portlet:defineObjects/>, <theme:defineObjects /> is also an empty tag without any attribute, and must be included after the mentioned directive. Lets see the objects:

1. ThemeDisplay themeDisplay - contains attributes such as groupId, company id, user id, if the user is logged in, etc..
2. Company company – Portal instance specific information
3. Account account – current user’s account object
4. User user – logged in user’s attributes
5. User realUser – in case of impersonation, gets the logged in user’s id
6. Contact contact – current user’s contact object
7. Layout layout – current page attributes
8. List<Layout> layouts
9. long plid - current portlet layout id
10. LayoutTypePortlet layoutTypePortlet – object having information about portlets on the current layout
11. long scopeGroupId – groupid of the current scope
12. PermissionChecker permissionChecker – attributes regarding surrent user’s permission
13. Locale locale – current user’s locale, determined by JVM
14. TimeZone timeZone – current user’s timezone, determined by JVM
15. Theme theme – attributes of current theme being rendered on the page
16. ColorScheme colorScheme – attributes of the current colour scheme of the current theme
17. PortletDisplay portletDisplay – attributes regarding name, ID, portlet mode etc.

That’s all for today. Thanks for reading and have a nice day.

Liferay: Understanding portlet:defineObjects

There is so much confusion about the implicit objects provided by <portlet:defineObjects/> tag on JSP as developers cannot see them easily. Experienced developers know what is available and they can use them freely. Here is a cheat sheet for the same.

<portlet:defineObjects/> is an empty tag without any attribute, and must be included after the mentioned directive.

JSR -286 (Portlet 2.0) have objects available from the following 13 objects, depending upon the origin of render, which lies in 3 categories:

1. Request Objects
1. RenderRequest – if the origin of request is from render phase
2. ActionRequest - if the origin of request is from action phase
3. ResourceRequest - if the origin of request is from ajax (serveResource)
4. EventRequest - if the origin of request is from event (processEvent)
2. Response Objects
1. RenderResponse - if the origin of request is from render phase
2. ActionResponse - if the origin of request is from action phase
3. ResourceResponse - if the origin of request is from ajax (serveResource)
4. EventResponse - if the origin of request is from event (processEvent)
3. Portlet Objects
1. PortletConfig
2. PortletSession
3. Map<String, Object> - contains list of all portletSessionAttributes
4. PortletPreferences
5. Map<String, String[]> - contains list of all portletPreferences

That’s all for today. Thanks for reading and have a nice day.

Liferay: IPC via Private Session Attributes

Every portlet WAR has a session associated with it. A portlet session is a java object. This session object can be used for sharing data between portlets and achieving IPC. So this article will explain IPC via portlet session.

To understand Portlet sessions, we have to understand session scope of the session object. There are two scopes – PORTLET_SCOPE and APPLICATION_SCOPE.

The data stored in the PortletSession of a portlet is not shared with any other portlets on the page, or anywhere else in the portal. This default behaviour is known as PORTLET_SCOPE. With the JSR-168(Portlet 1.0) portlet specification, concept of APPLICATION_SCOPE was introduced, and is available in its successor JSR-286(Portlet 2.0) which gives data access to all the portlets of the same WAR.

Let’s see the snippets:

Portlet 1: Setting Attributes:

PortletSession portletSession = renderRequest.getPortletSession();

// Application Scope
portletSession.setAttribute("appParam","I’m Sample App Scope Param Value", PortletSession.APPLICATION_SCOPE);
// Portlet Scope
portletSession.setAttribute("portletParam"," I’m Sample Portlet Scope Param Value ", PortletSession.PORTLET_SCOPE);

Portlet 2: Fetching Attributes:

PortletSession portletSession = renderRequest.getPortletSession();

// Application Scope
String appParam = (String) session.getAttribute("appParam", PortletSession.APPLICATION_SCOPE);
// Portlet Scope
String portletParam = (String) session.getAttribute("portletParam", PortletSession.PORTLET_SCOPE);

Portlet session attributes can be removed also, using the following:

PortletSession portletSession = renderRequest.getPortletSession();

portletSession .removeAttribute("appParam")
portletSession .removeAttribute("portletParam ", PortletSession.PORTLET_SCOPE);

Please note that both methods are interchangeable.

Liferay further provide feature for sharing portlet session attributes with portlet from other WARs. For achieving the same, we have to set <private-session-attributes> to false in liferay-portlet.xml.

That’s all for today. Thanks for reading and have a nice day. 

Liferay: Client Side IPC via Events/Ajax

Client Side IPC using Ajax is another way of achieving communicating between portlets from client size. This mechanism was introduced in JSR-286 (Portlet 2.0) specification and provides a very lightweight and decoupled mechanism to communicate portlets purely in the browser through a JavaScript events mechanism.

The API of this system is very simple and is based on two methods

Liferay.fire(eventName, data);

Liferay.on(eventName, function, [scope]);

Prerequisite for this includes - setting <requires-namespaced-parameters> to false, in liferay-portlet.xml file of the both the portlets, which makes allows to share data via Ajax call and adding both the portlets in the same page after deployment.

Let’s see some snippets:

Portlet 1: JS code for setting params

$(document).on('ready',function(){
 var param1 = "I'm a sample value of Param 1";
 var param2 = "I'm a sample value of Param 2";
 $.ajax({
  url:'',
  dataType: "json",
  data:{param1: param1, param2: param2},
  type: "get",
  success: function(data){
   Liferay.fire('setParamsViaAjax', {eventData: data});
   },
  complete: function(){
   alert('Success');
   },
  error: function(){
   alert(Some 'Error');
   }
 });
});

Portlet 2: JS code for fetching the Params

Liferay.on('setParamsViaAjax', function(event) {
 alert("Param 1: " + event.eventData.param1);
 alert("Param 2: " + event.eventData.param2);
}); 

That’s all for today. Thanks for reading and have a nice day.

Liferay: Client Side IPC via Cookies

I’m starting to write here again after long time. I was keeping busy while working on ReactJS and it’s integration with Liferay. However, I’m here continuing from where I left and will start about ReactJs and its integration with Liferay soon. 

In the previous two posts we’ve seen IPC via Public Render Parameter and Server Side Events. Today I’ll write about Client Side IPC at using Cookies. As IPC via Public Render Parameters and Server Side Events, this concept was also introduced in JSR 286.

Important point to note about Client Side IPC via Cookies is that we cannot have information stored/shared more than 4096 bytes in size, as this is the maximum size of a cookie allowed by browsers and maximum number of cookies allowed, varies browser to browser; which is, for example, 20 in case of IE and 600 in case of Safari Mobile. (You can read details here)

The scenario we’ll see here in snippet will be: creating the cookie in Portlet 1 and reading the same in portlet 2. I’m keeping name of the cookie ‘sampleIPCCookie’ for example.

Setting/Getting the cookie can be done by either of the method - server side (Java/JSP etc.) or client side (Javascript/JQuery etc.). Here I am writing example using of Javascript.

Let’s go and see the snippets.

Portlet 1: Setting the cookie 


Portlet 2: Fetching the cookie value in another portlet. 
Client Side IPC via cookies is not a best practice of IPC and should be considered as the last option for implementing IPC. If it is very necessary to implement IPC at client side, one should first consider Client Side Events (which we’ll see in the next post) before considering this mechanism.

That’s all for today. Thanks for reading and have a nice day.

Liferay: IPC via Server Side Events

IPC (Inter Portlet Communication) in Liferay can be implemented in different ways and  I've already written an article on Public render parameter mechanism. In this article, we'll see Event based IPC. As Public Render Parameters, this concept was also introduced in JSR 286.

As per IPC using Events, portlet can publish/send and process/receive the event. This mechanism works flawlessly with inter and intra WARs.

1. Event deceleration in Event Publisher Portlet's portlet.xml
Full portlet.xml will look like as follows:

2. Event definition in Event Receiver Portlet's portlet.xml
Full portlet.xml will look like as follows:
3. Event Publishing Portlet's Controller Class

Invoking Publish Event method

4. Event Processing Portlet's Controller Class and fethching parameter's value
Note: 'QName' is a nothing but a qualified name of the parameter. Usage of QName minimizes chances of having two identical events.

Liferay: IPC using Public Render Parameters

IPC (Inter Portlet Communication) in Liferay can be implemented in different ways and  we'll see one among the possibilities, i.e. Public Render Parameter. This concept was introduced in JSR 286.

The central idea of this concept is to share a normal parameter across all deployed portlets despite of the fact that they lie in same WAR or in different.

1. In portlet.xml in the end of </portlet> tag we have to define the name of parameter

2. In portlet.xml in the end of <portlet-app> tag we have to define the identifier with the name of parameter

Full portlet.xml file will look like as follows:

Setting Parameter:

Reading Parameter:

Note: If render parameters need to be shared among two different WARs, and you have to set parameter in portlet 1 and read in portlet 2, For achieving this, we have to add definition of render parameter in the portlet.xml file of both the WARs. 

Liferay: Instance Specific 'portal.properties' File

To start with this topic, we need to refresh the following:

Portal-ext.properties
Everybody who works with Liferay, know about portal-ext.properties file. Just to refresh, this file contains key-value pairs of settings and is present in the classpath to override the properties of portal.properties file (can be seen in Liferay source code or portal-impl.jar).

Liferay Portal Instance
Liferay Portal allows you to run more than one portal instance on a single server (e.g. tomcat instance). The Portal Instances page of the control panel lets you manage these instances. All portal data, however, is kept in the same database. (You can read in details here)

As a standard practice, the settings we do in portal-ext.properties file are shared among all portal instances. But with the settings we are now going to discuss will allow us to create different property files for each portal instance, and this is out of box only. To do so, we have to do the following two settings:

1. There are two ways of doing this, first you can set the following property in your system.properties file

or you can set this in your setenv.bat or setenv.sh as per your environment. You can enter the above entry just after '-Duser.timezone=IST' in the file.

2. Now we have to create properties file with the naming format 'portal-<<WebId>>.properties'. For instance, if the web id of the instance is 'finance', then the name of the property file for this instance will be portal-finance.properties.

Similarly we can create different property files for other portal instances. The default web id of liferay instance is 'liferay', so the name of property file for this instance will be 'portal-liferay.properties'.

Important things to note here is - not all properties can be overridden by this setting. Properties such as database configurations should be in the property file of default instance only.

For testing this, you can try to modify the authentication method. Change the value to screen name in the second instance's properties file while keeping the email (as default come bundled), you will get the second instance authenticating with screen name while the first with email address. It also works well while fetching the values using PropsUtil API. 

Liferay:Quick Reference to Asynchronous Message Bus

There are needs in practical scenario when it’s needed to do some huge processing in the background. It’s like some command is given to do something, while the application is not waiting for the response, such as sending bulk emails, handling scheduler’s requests, processing some data etc. Asynchronous message bus is great way to achieve this kind of requirement in Liferay.

The Message Bus is a mechanism for sending message payloads to different components in Liferay, providing loose coupling between message producers and consumers to prevent class loading issues. It’s located in the global class loader, making it accessible to every deployed web application. Remote messaging isn’t supported, but messages are sent across a cluster when ClusterLink is enabled.

Following are the message bus components which we'll use while implementing it:

1. Message Bus: Manages transfer of messages from message senders to message listeners.
2. Destinations: Addresses or endpoints to which listeners register to receive messages.
3. Listeners: Consume messages received at destinations. They receive all messages sent to their registered destinations.
4. Senders: Invoke the Message Bus to send messages to destinations.

We have to follow the steps given below, to create a message bus in Liferay:

Step 1: First of all we need to create messaging-spring.xml in /src/META-INF of your plug-in portlet. If you don’t have a service builder in the portlet, then you won't be having this META-INF folder, in that case you have to create a dummy service for the same. Now we have to put the following contents in this file:


Step 2: Now we have to make entry of this file in spring config. To do so, we have to open the service.properties file and make the entry of this file in "spring.configs" property.

Step 3: What remains wow is to create a class which should process the messages. This class must inherit the class MessageListener and should also implement method receive. (Please help yourself with proper imports)


Step 4: All set, now use the following code invoke this listener from your code from action class, scheduler etc. from wherever you want.

Thanks for reading.

Ref: Liferay Message Bus

Liferay: Connecting Portlet to an External Database Table

Sometimes we need to fetch data from two different databases in one project. There are several approaches, such as creating a new hibernate/spring session or fetching through web services. Both have their advantage and disadvantages. This article explains how we can create another session for fetching data from a database which is not configured as the portal's default database, but as some other (custom).
The problem with this approach is with the table creation, which is Liferay's obvious behavior. Why? I'll explain this in the end of this article.

1. First of all, create a new portlet with a service.xml file. Now build the service. For example, we create the following service. Here we need to know that the data-source value specifies the target data source which is the persistence class. The session-factory value specifies the session factory which is also set to the persistence class.The tx-manager value specifies the transaction manager which is used by Spring services. Rest of the things are pretty standard.

2. As we have built the service, Now its time to create table in the external database we're going to connect our portlet.

3. Now we have to supply the database connection details to our code. We can hardcode the database connection details directly in XML file directly, but its handy if  use the approach Liferay uses, i.e. through property file. So, lets just create some custom entries in portal-ext.properties file, not to mention you have to change the connection details as per your's:
4. As connection details now available, we have to use them to create a new session. So, for this we have to do spot the spring-ext.xml file which gets generated as soon as we build the service. The path of this file is: \docroot\WEB-INF\src\META-INF. We have to add the following entries in the end of this file:
Now we are done. We can now simple write LocalServiceInple code to access data from external database's table.

For the security reason, Liferay does not allow to create new table ontside the default DB. If you want to analyze liferay SRC, you can see the ServiceBuilder class's _createSQLTables method, where there is a condition check for default database.

You can download sample portlet from here. Hope this article will help you.

A Note of Liferay Portlet URLs

In a portlet, we get our code executed by two ways - at the time of rendering of the portlet and another on some action which is generally a form submit or some event. For getting the same done, we have three different URLs in Liferay:

1. Render URL (which is portlet URL and responsible for rendering of the portlet and in typical MVC portlet, the code of method doView() is executed)
2. Action URL (which is also portlet URL and responsible for performing some action with page reload and in typical MVC portlet, the code method processAction() is executed, and is followed by renderRequest)
3. Resource URL (which is NOT a portlet URL but it extends the same base URL, is responsible for performing some action without page reload i.e. Ajax and in typical MVC portlet, the code of method serveResource() is executed and is NOT followed bt render request, Resource Serving was not available in JSR168 but its avaible in JSR286.

We can create these URL mainly by four approaches:

1. Using TagLib
2. Using Java
3. Using Javascript (AUI)
4. Using Velocity

Now we'll see how we can create these three type of URLs with the above four approaches considering that you have done all necessary imports:

1. Using Taglib

Render URL:
here we are setting the window state of the portlet to maximum and a custom parameter(message).
Action URL:
Resource URL:

2. Using Java

Render URL:
Using RenderResponse:
Using PortletUrlFactory:
Action URL:
Using RenderResponse:

Using PortletUrlFactory:
Resource URL:
Using RenderResponse:
Using PortletUrlFactory:

3. Using Javascript (AUI)
Render URL:

Action URL:

Resource URL:

The following can be set on these portlet URL methods:

• setCopyCurrentRenderParameters: function(copyCurrentRenderParameters);
• setDoAsUserId: function(doAsUserId);
• setEncrypt: function(encrypt);
• setEscapeXML: function(escapeXML);
• setLifecycle: function(lifecycle);
• setName: function(name);
• setParameter: function(key, value);
• setPlid: function(plid);
• setPortletConfiguration: function(portletConfiguration);
• setPortletId: function(portletId);
• setPortletMode: function(portletMode);
• setResourceId: function(resourceId);
• setSecure: function(secure);
• setWindowState: function(windowState);
• toString: function();

4. Using velocity: Here we have to replace correct portletId and plid for getting the URL generated correctly.
Render URL:
Action URL:
Resource URL:
Hope you enjoyed the read.

A Note of Liferay Portal Instances

Liferay provides us facility to run more than one portal instance on a single server. Liferay comes with one inbuilt portal instance, which is names 'Liferay' and its web id is 'liferay.com', however it can be modified with following properties in portal-ext.properties file:

Note: There are several other properties regarding portal instances present in portal.properties as well which can be referred in Liferay Portal SRC.

If we login as administrator (generally test@liferay.com), and go to control panel we can see list of all available portal instances in 'Portal Instances' section inside 'Server' category. Here we will see a table with atlest one entry (inbuilt one) , lets know what the column of this table depicts:

• Instance ID: It’s a numeric Id, generated by code automatically at the time of Instance creation. Internally this Instance ID is referred as 'companyid' in the database table. We can see all available instances in database table 'company'.
• Web ID: It’s a user-generated ID for the instance. It can be anything relevant but a general convention is to use the domain name.
• Virtual Host: Domain name which is to be configured in the network kept here. This domain name is referred when users are directed to our Liferay server, and the same enables Liferay to resolve request for proper portal instance.
• Mail Domain: The domain name to be used as mail host for this instance kept here. Liferay will use this to send email notifications from the portal, and the same is used for creating the default test user, as test@mail-domain.com
• # of Users: Depicts current number of users on particular portal instance.
• Max # of Users: Depicts total number of users allowed on particular portal instance.
• Active: Depicts if the portal instance active or not (Yes / No).

Enough of theory, lets experience it. Startup the server and replicate the following steps:

1. Login as administrator. (test@liferay.com/test will work)
2. Navigate to Manage → Control Panel → Portal Instances section in 'Server' category.
3. By default only one portal instance will be listed. To add new, click on add button fill up the form fields. Say you have created 'newinstance.com'.
4. Assuming that you are working on your local system, you have to edit the host file (%SYSTEMROOT%\ System32\ drivers\ etc\ hosts). Add the following in the file:
   If you are in network then you can map the entry with the IP address of the server on which Liferay is running and try.
5. Start the browser (restart in case already running) and put 'newinstance.com:<PORT>' in address bar. What you see now in the new portal instance.
6. You can login as test@<domainname>, (test@newinstance.com in out case). This is the admin user of the instance. As an administrator you cannot see the 'Server' category in Control Panel, which means new instance can be created only from main portal instance.

If we dig in further, we will come to know that we can have different properties file for each portal instances. To enable this feature, set the "company-id-properties" system property to true. The read order will now be: portal.properties, then portal-ext.properties, and then portal-liferay.com.properties. Note that not all properties can have different values per company. This functionality is only available for legacy reasons. The preferred way to configure a portal instance is through the Control Panel.

Handling Portal Instances in Custom Code:
In real life scenario, we may need to process data differently for each Portal Instance in our custom code. So have a look on small code snippet:
Hope you enjoyed the reading.

Customizing Database Column Size

In most on the real life implementations, we need to use different datatype and and their sizes in database tables. As in Liferay, tables are created at the time of portlet deployment with the help of SQL generated by building of service.xml file, so we need to put all the table attribute information in configuration so that it can create table with the customized settings. The size of String is 75 by default. For customizing the same, we have to modify the portlet-model-hints.xml file. This file is available in META-INF directory inside src. To customizing the column size, we have to do the following:

Lest see the sample service.xml file:

Now we are going to modify the 'schoolName' and 'schoolDescription' attributes:

Now, after the deployment and creation of the table when you'll see table description, the 'schoolName' attribute will be of String type where as the 'schoolDescription' will be of varchar. Great! Indeed, but How the miracle happened? well, its not the magic, if length given in the model hints is greater than 4000 then the column type is converted in Varchar or Text automatically by Liferay but if length less than or equal to 4000 then column type will be String.

Enabling SSL in Liferay6.1.1-Jboss7.1.1 Bundle

My last post was about SSL in Liferay-Tomcat bundle. In the array, my this post about enabling SSL in Liferay-Jboss 7 bundle, in standalone mode. (We'll discuss about standalone and domain mode of Jboss in the next post)

Similarly there are two parts, first creating of certificates and another is configuration. For SSL certificate creation you can see my previous post. Now lets talk about settings. Go to the \liferay-portal-6.1.1-ce-ga2\jboss-7.1.1\standalone\configuration\ and open the standalone.xml file and follow the following steps:

1. Search for "urn:jboss:domain:web:1.1" and replace the <subsystem> ... </subsystem> contents with following:
   Again the password and certificate-key-file value will depend on your inputs at the time of certificate creation and default home directory.
2. Scroll further down and look for <interfaces> ... </interfaces> entry and replace whole with the following:
3. Now you the next block you will see will be of <socket-binding-group>, again replace the <socket-binding-group> ... </socket-binding-group> with the following:

That's it. Now start the server and use https://localhost:8181:/web/guest/ and enjoy! :)

You can download sample standalone.xml from here.

Enabling SSL in Liferay-Tomcat Bundle

For enabling the SSL (https) in Liferay-Tomcat bundle, we need to modify the server.xml file inside \liferay-portal-6.1.1-ce-ga2\tomcat-7.0.27\conf\ directory. By default the following entry is used:
There are basically two steps for enabling SSL. First - we need to create a self signed certificate (if you don't have one from publisher) and secondly setting up tomcat configurations. You can see approach for certificate creation in my previous post, only STEP 1 is sufficient for this purpose.

Now for enabling SSL, just put the following in server.xml

where the keystore password is the password used at the time of certificate creation.

Now start the server. You will be able to use https://localhost:8181/web/guest/ after complete startup. You can manage ports as per requirements.

You can download the sample server.xml file from here.

Creating Self Signed Certificate using Keytool

Prerequsites: For using the keytool utility, we have to ensure that our environment is configured to use the bin directory of JDK, otherwise the full path to the utility must be present on the command line. Which can be ensured by typing java or javac on command prompt.

There are basically three steps:
1. Generate the certificate in the keystore file

Here tomcat is an unique alias of certificate. change is the default password, you can change it. You now have a .keystore in the current user's home directory

2. Now export the certificate you just generated:

Now the certificate has been exported to server.crt file.

3. Now, add the exported certificate (server.crt) to your JRE's cacerts file

 Yes, now its done.

Creating Roles in Liferay with Portal-ext.properties

Need of user role is a very common in live scenario. One way is quite easy, just sign in as administrator, go to control panel and add one. But there is a drawback of this approach. If you are working on staging environment, you have to create this role in production environment when the code is deployed there. It means this is database specific and it will not move to production when the build is deployed on the server.

Liferay has provided us a better solution for the same. We can create role by using certain properties in portal-ext.properties file. We have to add the following properties in our portal-ext properties file.
Just restart the box after adding them, and go to the Roles section in Control Panel, you will be able to see both the roles added there.

Now if we want to access these roles in our code programmatically because this is basic need of creating role. So it can be done as following:
For getting users we can use the following methods:
Some other properties of portal-ext.properties that you can work on are:
Hope this will be helpful.

Solution of Duplicate Submission issue of Form on Page Reload

Re submission of form on press of refresh button is an old issue is Liferay. The reason behind this issue is the parameters and action which are available in URL after the form submission.  Earlier some developers used to open some other JSP after completion of Action.

But its solution is a very easy, provided by liferay itself. We have to set the following value in a tag inside liferay-portlet.xml which is set  false by default.

Liferay: Reading cookies in Theme Template

We can read the cookies in theme template using the following code:
Hope this will help.