LiquidSkin and WCI 10gR3 – Not Exactly a Happy Couple!

Every migration project has its unique challenges that, for the most part, get resolved with due diligence. Yet, some issues, let’s put it this way, can be more distinct.

Recently, I was on a client project migrating from ALUI 6.1 to WCI 10gR3. Beside overcoming the usual quirks with SSL, security certificates, notification service, analytics, and upgrade documentation that seems to cover 90% of what needs to be done and leaves 10% for us to improvise, I had issues with LiquidSkin. You remember that product developed some time ago for BEA Systems when WCI was still ALUI?

A quick refresher: LiquidSkin is a set of libraries you can add to a portal install to customize the portal menu styles (dropdown, tabbed, vertical or horizontal navigation, …), the styles around portlets, pages, and communities and a whole slew of customizable navigational styles. The customization is defined in XML files that map to experience definition objects. Within the XML, you can target the customization to specific sections on a portal page; e.g. above banner, below banner, below body, above footer, etc. After the Bea acquisition, Oracle kept the assemblies current but I'm not sure if it has been thoroughly tested with WCI 10gR3.

So, after migrating this customer's development environment to 10gR3, upon a first visit to a community, the skin defined in the experience definitions for that community rendered properly. All objects were rendered with their respective skin settings; e.g. portlets colors, page background color, etc. However, after a subsequent navigation to a different community with a different experience definition, the skin attached to it did not load. Instead, the target community was rendered with the skin attached to the community visited first. You can imagine this: a community with correct page and portlets but incorrect styles and navigational menu below the banner!

The first thing that came to our mind is the caching setting that is defined for each section in the LiquidSkin.xml for that experience definition. The setting were:

<sCacheMode value="NONE" />

<iCacheLifetime value="0" />

which indicate that caching is disabled for that particular section; all other sections had the same setting in the XML file.

I compared the IIS portal web site settings between 6.1 and 10gR3 and they were identical. I insured that the adaptive page layout for each experience definition object is disabled. After extensive fruitless digging, it seems that moving away from LiquidSkin to adaptive layouts for styles and navigation is the most feasible option. But we are still looking into this and will post an update if we discover a resolution.



Stay In Touch