Overview

Liferay Ext Plugins are often considered a last resort in the Liferay Plugin world due to the complexity and the lack of hot deploy as well as the inability to remove them once they are deployed. These difficulties come from the fact that they are as close as you can get to customizing the core Liferay code without actually doing it. The difference being it keep's your customizations separate from the Liferay code which helps at upgrade time or when the customization can be removed which is often the case when modifying the upgrade process.

I would like to cover two scenarios where Ext plugins were very useful for me and provide examples that can be of use to other people. The first is customizing the Liferay upgrade process and the other is customizing the LDAP import process.

Customizing the Liferay Upgrade Process

This section covers how to customize the Liferay Upgrade Process. I ran into a problem during my upgrade process with the following error showing up 1000's of times. Its trying to add new Social Activity for each of my Wiki Pages. However it says that more than one Wiki page was updated at exactly the same time/day/second which according to the SocialActivity table (and reality) is not possible.

Create a new Liferay Extension plugin and copy com.custom.portal.upgrade.UpgradeProcess_6_2_0 and com.liferay.portal.upgrade.v6_2_0.UpgradeSocial to ext-impl in the new plugin. Rename both classes so they start with Custom.

Modify CustomUpgradeProcess_6_2_0 to include your new CustomUpgradeSocial. Change upgrade(UpgradeSocial.class); to upgrade(CustomUpgradeSocial.class);

Modify CustomUpgradeSocial to check for the existence of duplicate time stamps to avoid the problem from above.

Modify the portal-ext.properties file to include the custom upgrade process as opposed to the default one:

There is also example for customizing the verify process with a fix for LPS-42839 included.

Make sure to add the following to the portal-ext.properties file:

verify.processes=com.custom.portal.verify.CustomVerifyProcessSuite

If all goes well the upgrade process should show:

Verifying com.custom.portal.verify.CustomVerifyDocumentLibrary

Customizing the LDAP Import Process

I wanted to customize the LDAP import process to import the Address and Phone number from LDAP. I know that you can import them as custom attributes today but I wanted them to actually show up in the Phone and Address section in the user profile. That way I could populate the Contacts Center in Social Office with data that was already in LDAP.

A while back Michael Han wrote a nice article explaining that the LDAP export/import process could be overridden using Spring. I went ahead and implemented a custom LDAP import process using the ext-spring.xml file found in an extension plugin and was able to customize the LDAP import process.

In the Liferay Developers Guide there is a nice little tidbit titled "Creating Plugins to Extend Plugins" found here. This basically allows a lot of the same principles used with hook plugins when customizing Liferay. The difference here is that it allows you to customize portlet plugins with plugins. As with hook plugins this allows a degree of separation between your customization's and the default application.

This same concept can also be used to customize Social Office plugins (including Social Office EE plugins). The name of the new plugin must match the name of the original plugin since the so-hook expects the original name.

We had a need to hide the two public Site types in Social Office (Open and Public Restricted) since we share our Portal instance with our Clients.

Run the all Ant task. A new tmp directory will show up at the root of the so-portlet project (may need to refresh). At this point this is the contents of the original war file.

Copy tmp/WEB-INF/liferay-plugin-package.properties to docroot/WEB-INF in the so-portlet project (Create WEB-INF if it doesn't already exist).

Modify liferay-plugin-package.properties and change module-incremental-version to 10. This will cause your custom so-portlet to always take priority over the default so-portlet.

Copy tmp/sites/edit_site.jsp to docroot/sites

Modify docroot/sites/edit_site.jsp and remove the lines that define Public and Public Restricted Sites (Search for TYPE_SITE_OPEN and TYPE_SITE_PUBLIC_RESTRICTED).

Run the all Ant task again and now tmp will be a combination of the default war file and your cusomizations. This also generates a custom war file in the plugins SDK dist folder that can be deployed to a Liferay server

That's pretty much it. This procedure can be used with pretty much any portlet project including EE versions.

In Verbindung stehende Assets:

Forrester Groundswell Awards honors initiatives that represent excellent and effective use of social technologies to advance an organizational or corporate goal.

CDS Global choose Liferay Portal 6.1 EE GA2 for implmenting our new Share Chain. Liferay's Open Source roots such as the power to take control of the software and customize it to our needs allowed us to quickly and easily implement the new requirements.

The Share Chain uses Liferay's Message Board componement to allow employees to request collective support for spreading important news across an individuals' social networks.

Harnassing the power of a customized Asset Publisher along with Tags and Catergories we can easily aggregate many types of content into a centrailized Social Business Hub page in Liferay including the entries from the Share Chain Message Board.

A Forrester Groundswell award would be very benficial for both Liferay and CDS Global as a whole. Please take a moment and vote by clicking the link below and looking for "My rating: " below the screenshot in the right-hand column.

With the release of the Liferay IDE 1.1 I got to thinking it would be really cool to try and build the Social Office Trunk using the Liferay IDE. I thought I could get a way with using Liferay Portal nightly builds and then build Social Office on top of that. As it turns out its still easier to check out the Portal trunk and build it manually and then add Social Office on top of that.

In the end I was able to convert all of the components that make up Social Office into Liferay IDE projects and deploy them to a Liferay 6.1 trunk build.