Liferay Tech Support: Frequently asked questions

Table of Contents [-]

This article needs updating. For more information, see Wiki - Need Updating.

Installation and mantainance #

What is the difference between Liferay Portal Enterprise Edition and Liferay Portal Community Edition?#

What do I do if I am getting Out of Memory Error?#

Out of memory errors can occur for a variety of reasons. One suggestion is to increase the amount of memory in your startup options for your application server/container. The following JVM options control memory usage in Java: --Xms128m (default) --Xmx512m (default) --XX:MaxPermSize=128m (recommended)
Recommendation: Since Liferay loads a lot of jars, more specifically classes, a MaxPermSize of 128m is recommended. It's also good practice to up the maximum heap size to 1024m (-Xmx1024).
There are a number of other parameters that you should be configuring to optimize your JVM memory usage, especially if you are using JDK 1.5+. Significant improvements have been seen by tuning the new and old/tenured generation in your garbage collector (see http://blogs.sun.com/watt/resource/jvm-options-list.html ).
Where to make these configurations:

Windows/tomcat: catalina.bat
Linux/tomcat: catalina.sh

What version of Java/Jikes should I use with Liferay 4.x?#

It is recommended that Liferay 4.x is run on JVMs 1.4.2 or 1.5. If you use 1.4.2, you will need Jikes 1.2.1; if 1.5, use Jikes 1.2.2. As of 4.4.0, Jikes is no longer configured as the default for Liferay and therefore not needed.

Why can I do if I get a "Path too long" error when unzipping a bundle?#

If you are using the default Windows zip file extractor to unzip Liferay, you may get this error. Switch to a dedicated unzipping utility like 7-Zip or WinZip and you should be able to unzip the file.

What are some suggestions on improving start up time under a VM?#

It may take several (five-plus) minutes to reboot Liferay. We are running 4.1 Liferay Enterprise in a virtual web server. I've removed unused portlets to try to cut down the booting speed, but that doesn't help much. What are other ways available to speed up? Of course, a physical server rather than a virtual server will help. What else?
Adding more memory to the JVM via the argument of: -Xmx1024m will help. Depending on what you are using Liferay for, you can remove uneeded webapps under /webapps (for Tomcat).
Another thing that will help is to set:
index.on.startup=false
in portal-ext.properties. This property tells Lucene not to reindex content that is part of the portal.

When I try to connect to Liferay I get a NPE at StrutsUtil. #

The uri variable that is null is a string that comes from the portal.properties "servlet.service.events.pre.error.page" That property seems to be commented out by default.
This error should only occur when using Tomcat 5.5.20 with Liferay 4.1.2. Reverting back to Tomcat 5.5.17 should fix the problems on Windows; On Linux Tomcat 5.5.20 should work fine.

Uploading an image to the image gallery throws an error. #

This usually means that an entry in the Image is on in sync with the primary counter in the Counter table.
Open a SQL console with the following query:
select * from Counter;
Take note of the value for com.liferay.portlet.imagegallery.model.IGImage.liferay.com. Take a look at the imageId for the last entry in the IGImage table.
Increase com.liferay.portlet.imagegallery.model.IGImage.liferay.com to a value greater than is in the imageId field.

How do I deploy Liferay to a context different than ROOT (starting with Tomcat 5.5 standalone) #

Download Apache-Tomcat 5.5.23 and extract to c:\apache-tomcat-5.5.23
Download Liferay Portal Tomcat 5.5.23 (JDK 5) bundle and extract to c:\liferay
Rename the c:\liferay\webapps\ROOT folder to c:\liferay\webapps\liferay-portal
Copy the c:\liferay\webapps\liferay-portal folder to c:\apache-tomcat-5.5.23\webapps
Rename the c:\liferay\conf\Catalina\localhost\ROOT.xml file to liferay-portal.xml, and edit the file, so that the first line looks like this:

<Context path="/liferay-portal" crossContext="true">

Copy the c:\liferay\conf\Catalina\localhost\liferay-portal.xml file to c:\apache-tomcat-5.5.23\conf\Catalina\localhost
Copy the c:\liferay\common\lib\naming-factory.jar file to c:\apache-tomcat-5.5.23\common\lib (Note: This naming-factory.jar contains JavaMail SMTP classes, whereas the default Apache-Tomcat one does not)
Copy the c:\liferay\common\lib\ext folder to c:\apache-tomcat-5.5.23\common
Copy the c:\liferay\common\endorsed\*.jar files to c:\apache-tomcat-5.5.23\common\endorsed
Copy the c:\liferay\server\lib\support-tomcat.jar file to c:\apache-tomcat-5.5.23\server\lib
Edit the c:\apache-tomcat-5.5.23\conf\catalina.properties file, and append the following text to the common.loader value:

,${catalina.home}/common/lib/ext/*.jar

Edit the c:\apache-tomcat-5.5.23\webapps\liferay-portal\WEB-INF\classes\portal-ext.properties file, and add this line:

portal.ctx=/liferay-portal

Edit the c:\apache-tomcat-5.5.23\bin\catalina.bat file, and add the following line after the “Execute The Requested Command” REM statement:

set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx1024m -XX:MaxPermSize=128m -Dfile.encoding=UTF8 -Duser.timezone=GMT -Djava.security.auth.login.config=%CATALINA_HOME%/conf/jaas.config

To login to the portal, visit this URL: http://localhost:8080/liferay-portal

How do I deploy Liferay to a context different than ROOT (starting with Liferay/Tomcat-5.5 bundle) #

1) Edit or create in classpath the configuration file portal-ext.properties and set:

portal.ctx=/mycontext

2)
2.1) Liferay 4.3, 4.4, 5.x and later as well as the WAR edition in previous versions:
Many application servers support a simply rename of the war to mycontext.war.
In Tomcat, you may also: create META-INF/context.xml

<Context path="**/mycontext**" reloadable="true" >
    
    <Resource
        name="jdbc/LiferayPool"
        auth="Container"
        type="javax.sql.DataSource"
        driverClassName="com.mysql.jdbc.Driver"
        url="jdbc:mysql://localhost/lportal?useUnicode=true&characterEncoding=UTF-8"
        username="root"
        password=""
        maxActive="100"
        maxIdle="30"
        maxWait="10000"
    />
    
    <Resource
                name="mail/MailSession"
                auth="Container"
                type="javax.mail.Session"
                mail.transport.protocol="smtp"
                mail.smtp.host="localhost"
    />
    
    <Realm
                className="org.apache.catalina.realm.JAASRealm"
                appName="PortalRealm"
                userClassNames="com.liferay.portal.security.jaas.PortalPrincipal"
                roleClassNames="com.liferay.portal.security.jaas.PortalRole"
                debug="99"
                useContextClassLoader="false"
    />
   </Context>

2.2) Liferay version 4.2 and previous enterprise (EAR) edition:
edit liferay_portal.ear/META-INF/application.xml and set:

<module>
      <web>
         <web-uri>portal-web.war</web-uri>
         <context-root>/mycontext</context-root>
      </web>
   </module

3) Edit the deployed web.xml and set the root_path context-param:

<context-param>
      <param-name>root_path</param-name>
      <param-value>/mycontext</param-value>
   </context-param>

In the enterprise version, this file is contained inside portal-web.war/WEB-INF.
4) Change the name of the WAR to mycontext.war (this is not necessary for some application servers)
'Note: Step 5 is no longer necessary as of Liferay v.4.3.x'
5) Edit /html/index.html: <body onLoad="javascript:location.replace('/mycontext/c')">

What jar versions does Liferay run? #

In "\lib", you'll find a file called versions.txt that will tell you what jar versions Liferay has loaded.

Customization and administration #

How do I customize the General Guest pages?#

Log into the portal with as a privileged user to change General Guest layouts. Switch to the General Guest community. Configure the page.

How can I disable portlets bundled with Liferay #

If you are using some bundle edit liferay-portlet.xml in portal-web/WEB-INF and use the 'active' element to disable the portlets that you don't want:

<portlet>
    ...
   <active>false</active>
 </portlet>

If you are using the ext environment you don't have to modify the original liferay-portlet.xml file. Just edit liferay-portlet-ext.xml and add an entry for every portlet that you want to disable.
Disabled portlets are never loaded by liferay so they don't consume any CPU cycle or memory space.

Note:
If you edit the active/inactive state of the portlets in the GUI Admin portlet, a record will written to the database. The database record takes precedence over the XML configuration file described above. Therefore, after editing the state of the portlets via the GUI Admin portlet, any subsequent change to the XML config file's portlet state will not take effect, because the database takes precedence.

As of Liferay version 4.3.4 you this functionality is bugged. To edit the state of your portlets you will have to use the GUI Enterprise Admin portlet.

How can I change the initial page of a Liferay portal? #

There is an index.html file that is the first one that is read and redirects to the initial page. Modify that file and set the redirection to a different URL.
The default is '/c' which takes the user to the guest community if he/she is not logged on yet or to his private pages otherwise.
FIXME - now it's a jsp that invokes PortalUtil.getPathMain()

Can I change the page where users are redirected after login? #

Currently after login users with the 'Power User' role are forwarded to their desktop. There is currently no way to modify this default behavior.
There is a issue filed in JIRA to keep track of this feature request: http://support.liferay.com/browse/LEP-1420
Meanwhile it is possible to use the ext environment and some programming to achieve this: http://www.liferay.com/web/guest/devzone/forums/message boards/message/25021

How do you completely hide portlets with borders that users don’t have permission to see? #

To change this feature for all the portlets in the portal, set the following parameter in portal.properties to "false":
layout.show.portlet.access.denied=false
To change this feature on a per portlet level, set the "show-portlet-access-denied" parameter in liferay-portlet.xml to "false" for a particular portlet. The setting in liferay-portlet.xml will override the setting in portal.properties.

How do you completely hide portlets with borders that are inactive? #

To change this feature for all the portlets in the portal, set the following parameter in portal.properties to "false":
layout.show.portlet.inactive=false
To change this feature on a per portlet level, set the "show-portlet-inactive" parameter in liferay-portlet.xml to "false" for a particular portlet. The setting in liferay-portlet.xml will override the setting in portal.properties.

How do you include CSS and JavaScript in a portlet? #

There are 3 ways you can include CSS and JavaScript code.
1) You can use the theme for the page. The CSS code is stored in the following JSPs:

/ext/ext-web/docroot/html/themes/[theme name]/templates/css.jsp
 /ext/ext-web/docroot/html/themes/[theme name]/templates/css_cached.jsp

and the JavaScript code is stored in the following JSPs:

/ext/ext-web/docroot/html/themes/[theme name]/templates/javascript.jsp
 /ext/ext-web/docroot/html/themes/[theme name]/templates/javascript_cached.jsp

2) You can include both directly in the portal in the following file:

/ext/ext-web/docroot/html/common/themes/top_head.jsp

3) You can use the "header-css" and "header-javascript" parameters per portlet in liferay-portlet.xml. Use the following as a reference:

/portal/portlets/sample-jsp-portlet.war/WEB-INF/liferay-portlet.xml

A more detailed method for optimizing Javascript load in the browser is explained in Including Javascript / JS Files in a portlets

How do we use the session to share attributes between portlets deployed as individual WARs? #

Overview: All portlets (both in the Liferay EAR and deployed as individual WARs) are able to share attributes using the default HttpSession object using 2 different methods
NOTE: If all portlets are packaged in the same WAR, those portlets will share the same session, but they will have a different session than the portal since the portal is in its own WAR.

Method 1 - Sharing attributes between portlets:
This method involves giving portlets access to the portal’s session. Namespacing is not used in this method. This method is desirable for most scenarios, however there is the potential for a portlet to overwrite another portlet’s (or even the portal’s) attributes being stored in the session. For example, suppose after a user logs in, the portal sets an object called “user” in the session. If one of the portlets were also to set an object called “user” in the session, the previous “user” object would be clobbered. Note: the private-session-attributes element is only available starting with 4.2.0
1) In the liferay-portlet.xml of each WAR, set the following parameter to false for all portlets that should be able to share session attributes (it defaults to true):

<private-session-attributes>false</private-session-attributes>

2) In your Action classes or JSPs, use code similar to the following to set attributes in the session (this is exactly like a default setAttribute() call):

session.setAttribute("id", "1234567890");

3) In your Action classes or JSPs, use code similar to the following to retrieve attributes from the session (this is exactly like a default getAttribute() call):

String id = (String)session.getAttribute("id");

Method 2 - Sharing attributes from the portal to portlets:
Since portlets deployed in different WARs have different sessions than the portal, this method involves copying namespaced session attributes from the portal session to each of the portlets’ sessions. The pro of this method is that attributes will never be accidentally overwritten as in Method 1. The con is that attributes can only be written from the portal to the portlets. In other words, the portlets can not update the attributes…they can only read them. Note: the private-session-attributes element is only available starting with 4.2.0
1) In the liferay-portlet.xml of each WAR, set the following parameter to true for all portlets that should be able to share the namespaced session attributes (it defaults to true):

<private-session-attributes>true</private-session-attributes>

2) In portal-ext.properties, override the following property and supply a comma-delimited list of values to use for namespacing attributes that should be shared by all portlets:

session.shared.attributes=LIFERAY_SHARED_

3) In your portal classes (e.g., LoginPostAction), use code similar to the following to set attributes in the portal session that you want to be shared among all portlets:

session.setAttribute("LIFERAY_SHARED_id", "1234567890");

4) In your portlet Action classes or JSPs, use code similar to the following to retrieve attributes from the session that have been set by the portal:

PortletSession psession= req.getPortletSession();
 psession.getAttribute("LIFERAY_SHARED_id", PortletSession.APPLICATION_SCOPE);

How do we use the request to share attributes between portlets deployed as individual WARs? #

Overview: All portlets (both in the Liferay EAR and deployed as individual WARs) are able to share attributes using the default HttpServletRequest object using 2 different methods
Method 1 – Sharing attributes without namespacing
' NOTE:'' This method can possibly result in a ClassCastException (especially for multiple portlets in multiple WARs) and is therefore not recommended.
This method involves giving all portlets access to the same request. Namespacing is not used in this method. Because all the portlets are sharing the same request, it is possible for them to overwrite each others’ attributes (as described with session above). Due to this fact, it is recommended to use Method 2 below.
1) In the liferay-portlet.xml for each WAR, set the following parameter to false for all portlets that should be able to share request attributes (it defaults to true):

<private-request-attributes>false</private-request-attributes>

2) In your Action classes or JSPs, use code similar to the following to set attributes in the request (this is exactly like a default setAttribute() call):

request.setAttribute("id", "1234567890");

3) In your Action classes or JSPs, use code similar to the following to retrieve attributes from the request (this is exactly like a default getAttribute() call):

String id = (String)request.getAttribute("id");

Method 2 – Sharing attributes with namespacing
This method only allows namespaced attributes to be shared by all the portlets through the request.
1) In the liferay-portlet.xml for each WAR, set the following parameter to true for all portlets that should be able to share namespaced request attributes (it defaults to true):

<private-request-attributes>true</private-request-attributes>

2) In portal-ext.properties, override the following property and supply a comma-delimited list of values to use for namespacing attributes that should be shared by all portlets:

request.shared.attributes=LIFERAY_SHARED_

3) In your Action classes or JSPs, use code similar to the following to set attributes in the request that you want to be shared among all portlets:

request.setAttribute("LIFERAY_SHARED_id", "1234567890");

4) In your Action classes or JSPs, use code similar to the following to retrieve attributes from the request that have been set by another portlet:

String id = (String)request.getAttribute("LIFERAY_SHARED_id");

Does Liferay support clustering? #

Yes, Liferay does support clustering. In general, it is handled as you would any other clustered environment. Usually, a load balancer is put in front of a farm of servers. Objects in Liferay are cached per server in the server cache. Liferay provides support for Ehcache so that if any object is modified, a broadcast message is sent out to all servers in the cluster to invalidate their caches and retrieve the updated object from the database. The configuration for Ehcache in a clustered environment is controlled in 3 properties files:

portal.properties – Search for the “Ehcache” section and follow the documentation in the comments

ehcache.single.vm.config.location – Properties for caching objects that do not need to be synchronized across the cluster

ehcache.multi.vm.config.location – Properties for caching objects that do need to be synchronized across the cluster

The config files are loaded from the Java classpath.
Also see:

Is there a way to clean up the portal database? #

In the /portal/sql directory, we have ant scripts to clean (meaning drop) and recreate/rebuild all the databases that we support. We will always provide upgrade scripts if new versions of Liferay require changes to the existing database.

Is there a setting to cache or improve the performance for going to the database for Liferay? #

As mentioned above, by default, we use Ehache for caching objects in Liferay. We also support other cache providers, but Ehcache is the only one we support in a clustered environment. You can change your cache provider in portal.properties by changing the hibernate.cache.provider_class property. Many of our customers use a database cluster to improve performance. We often recommend Sequoia as an open source alternative. Most of our larger clients use database clustering, primarily for failover purposes.

When the portlets are hit the first time it takes longer than subsequent requests. Is there a way around the “first hit performance penalty”? #

You can pre-compile the JSPs. That’s the only performance enhancement to make.

Is there a way to cache Javascript, CSS and image files? #

Yes, Javascript, CSS, and image files can all be cached in Liferay. For Javascript and CSS, look in any of the themes’ “templates” directory. You’ll find 2 JSPs there – css_cached.jsp and javascript_cached.jsp. They do exactly what you’d expect. As for image files, any images that are stored in our database will be cached like any other object via OSCache, and any images that actually live on the server will be cached by your browser unless you turn that off.

Can you export a Liferay Archive (LAR) from one portal server and import it into another portal server? #

Yes, as long as the 2 portal servers are running the same version of Liferay. When you export a LAR from a community, you are exporting that community’s pages, layouts of the portlets on the pages, each of the portlets’ preferences, and a pointer to the theme for each page. If you import the LAR into a portal server that doesn’t have a certain theme available, it will default to the default theme (usually “classic”). If you import a LAR that doesn’t have a certain portlet available, a message saying that portlet is not available will appear in the portlet’s space.

How do you set objects in the session after logging into the portal? #

1) In portal-ext.properties, override the following parameter and add your own post login action class:

login.events.post=com.liferay.portal.events.LoginPostAction,com.my_company.portal.events.LoginPostAction

2) Your LoginPostAction class should extend com.liferay.portal.struts.Action, and it needs to have a run() method defined with the following signature:

public void run(HttpServletRequest req, HttpServletResponse res) throws ActionException

You can use com.liferay.portal.events.LoginPostAction as a reference.
3) In the run() method, you can do any processing you need to get the objects, access the HttpSession via the HttpServletRequest object, and set your objects in the session.

How do you deploy an EAR file to JBoss from the ext environment? #

In your app.server.USERNAME.properties file, add the following 2 parameters:

app.server.jboss-tomcat.deploy.archive.type=ear
 app.server.jboss-tomcat.deploy.archive.unpack=false

When you run “ant deploy” from your ext environment, this will tell the build script to create a physical EAR file (not an exploded version) and copy it to your JBoss deploy directory.

Note: This applies to Liferay version 4.2 and above.

How do you display/store images in Liferay? #

There are 2 ways to display images in Liferay:
1) There is a portlet called "Image Gallery" that can be used to upload images to the portal. These images can then be accessed in your HTML in the following way:

<img src="/image/image_gallery?img_id=1001">

Obviously, this may not be the optimal way to access images because you would have to know each image's ID in order to display it. However, this is probably the quickest and least intrusive way to do it.
2) Images can be put into the theme of your page. Each theme has the same directory structure, and one of those directories is the "images" directory. Within the images directory, we've further divided the image files into more granular directories (e.g., blogs, document_library, message_boards, etc.). You can create your own directory and place any image files that you may need here. You would then access the files in the following way:

<img src="<%= themeDisplay.getPathThemeImage() %>/your_portlet/some_image.gif">

How do you associate new users with default communities? Is there a way to set their default page to a particular community page? #

There are 2 ways to accomplish associating new users with default communities...one via the GUI and one using a properties file.
Via the GUI, go to the Admin portlet, click on the Users tab, and click on the Default Associations tag. There will be a textbox with the label "Enter the default community names per line that are associated with newly created users". Enter each community name on separate lines. Click the Save button. From now on, every time a new user is created, the user will be associated with these default communities
Second, you can override the admin.default.group.names property in portal.properties to do the exact same thing. For example:

admin.default.group.names=Support\nHuman Resources\nSales

Notice that the community names are separated by "\n"...this corresponds to the line breaks using the GUI.
Currently, there is no way to choose which community home page will display when the user first logs in. Basically, the first community alphabetically in the list will be displayed. In the example above, the Human Resources home page would be displayed.

How do turn Hibernate SQL on so I can view it in the logs? #

In portal-ext.properties, put this line:

hibernate.show_sql=true

What is the difference between an organization and a community? #

Since Liferay v4.4 organizations are much more powerful than they used to be. Specifically there can be many levels in the hierarchy of organizations, its administration can be delegated (through Organization Roles) and users can belong to more than one organization (and have a different role in each).
With this in mind the main difference with communities are:

Users *belong* to an organization which means that the org admin is able to edit her profile. OTOH users *join* a community which means that the community admin can only manage the membership.
Organizations can form a hierarchy while communities are independent of each other
Users must belong to an organization while joining a community is optional (not that this is actually configurable)

How can I use my custom utilitys/Spring-Services in Velocity templates? #

Velocity Template

##portal_normal.vm

#set ($myService = $request.getAttribute('myService'))

Foobar: ${myService.find('foobar')}

ServletFilter

public class TemplatingRequestAttributesFilter extends OncePerRequestFilter {
     private static final String MY_SERVICE = "myService";
     private MyService service;

protected void initFilterBean() throws ServletException {
         super.initFilterBean();
         WebApplicationContext webctx = WebApplicationContextUtils.getWebApplicationContext(getFilterConfig().getServletContext());
         this.service = (MyService)webctx.getBean(MyService.class.getName());
     }

protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException {
         try {
             request.setAttribute(MY_SERVICE, entryRetrieverFacade);
             chain.doFilter(request, response);
         } finally {
             request.removeAttribute(MY_SERVICE);
         }
     }
 }

web.xml

<filter>
     <filter-name>TemplatingRequestAttributesFilter</filter-name>
     <filter-class>de.kqv.liferay.filter.TemplatingRequestAttributesFilter</filter-class>
 </filter>
 <filter-mapping>
     <filter-name>TemplatingRequestAttributesFilter</filter-name>
     <url-pattern>/c/portal/layout</url-pattern>
 </filter-mapping>
 <filter-mapping>
     <filter-name>TemplatingRequestAttributesFilter</filter-name>
     <url-pattern>/c/portal/css_cached</url-pattern>
 </filter-mapping>
 <filter-mapping>
     <filter-name>TemplatingRequestAttributesFilter</filter-name>
     <url-pattern>/c/portal/javascript_cached</url-pattern>
 </filter-mapping>

How do I delete a user? #

This is a two step process in the Enterprise Admin portlet:

Deactivate that user
Search by non-active users and delete that user

Security and Performance #

How many concurrent users can I have per server? #

This is a very broad-ended question and really needs to be answered on a case-by-case basis. If the primary use of Liferay is as a CMS with very few logged in users, the number of hits per user can be quite high. If the common use is to login and have custom permissions for each user for specific portlets and portlet data, the number of concurrent users may be significantly smaller. This will also depend on what JVM the client is using, how the JVM is configured, what Servlet Container is used, whether or not an Application Server is used, what portlets and servlet filters are enabled within Liferay, etc. Though a healthy amount of memory (2-4GB for a 32-bit OS, more for a 64-bit OS) is always encouraged for each server, as you begin to ramp up the number of users, Liferay will often be more CPU-bound under load than memory-bound. The specifics of this are on a case-by-case basis, and is also greatly dependent on any custom code deployed Liferay. It is also important to recognize that a common bottleneck is the database (hence, much of its data is cached within Liferay's second-order caching).
A couple tips on this area: DO PERFORMANCE TUNING SOONER THAN LATER. This is a major task that, for the experienced test engineer, will take at least two weeks to get all the kinks out -- and the result may be to (1) improve your custom code, (2) upgrade your hardware, (3) add more hardware, or (4) upgrade to a newer version of Liferay (we almost always have performance improvements in every major version). In order to determine whether you are CPU-bound or memory-bound, see this blog. Generally, most people will find that the system is memory-bound (until you tune the JVM's memory usage), then you will find that it is CPU-bound.

How secure is Liferay Portal? #

James McGovern is an Enterprise Architect for The Hartford Financial Services Group, Inc. (a Fortune 100 company), and he specializes in security. He has performed independent security audits on Liferay with very positive results. Here are 3 postings from his blog:

http://duckdown.blogspot.com/2006/08/techforum-thoughts-on-secure-software.html

http://duckdown.blogspot.com/2006/10/challenge-to-open-source-vendors.html

http://duckdown.blogspot.com/2006/12/why-open-source-is-more-secure-than.html

In addition, Symantec (makers of antivirus and security software) uses our portal in one of their products known as i3, and Borland JBuilder bundles Liferay for their TeamInsight portal

Are there any performance benchmarks available for Liferay? #

The following 2 links provide information on benchmarks as well as how Liferay has been able to scale with a large user base:

http://www.eweek.com/article2/0,1895,1983364,00.asp

http://www.liferay.com/products/liferay-portal/stories/educa-madrid

Content Management #

Is there a way to post multi-page articles that have pagination? #

Yes! As of version 4.4.0+ you can insert a @page_break@ token into your contents (or emitted by your templates).

Theme related small trick #

How can I give all my users the ability to Maxmize and Minimize portlets abilities only? #

For guest we can do in portal-ext.properties while for users u need to customize portlet.vm file of your theme. it can be done like this #if ($permissionChecker.isCompanyAdmin($company_id))
$theme.iconOptions()
$theme.iconClose()
#end
so admin only can see all icon . and all other users will get only maximize and minimized icon. Don't forget to stop and start the server after modifying vm files...

Wednesday 18 May 2011

Frequently asked questions