Migrate themes

When migrating themes that were developed in an earlier version, you need to be aware of general guidelines, differences, and known issues.

With version 7.0, custom themes and skins that are present in the wps.ear file on the source server prior to migration are consolidated in the MigratedThemes.ear file on the target server after migration. This not only makes maintenance more straightforward, but it also provides you with an easier way of verifying and updating themes for the migrated environment without impacting other parts of the portal. By starting with MigratedThemes.ear and modifying the themes and skins, you can then deploy the new EAR and make the updated themes and skins available to the portal.

When migrating themes, be aware of the following considerations:

• Migrated themes should be applied to the same pages that they were designed for in the earlier version.

• Migrated themes should be used with the same skins as in the earlier version. Some skins in the current version take advantage of functions that were not available in the earlier version.

• To ensure that the person tag works as expected, customized themes must be migrated to include Semantic Tag Service. When you migrate customized themes, verify the current theme's header file (usually either head.jspf or head_externalJS.jspf) includes the following line at the end, just before </head>:

  <script type="text/javascript" 
  src="/wps_semanticTag/javascript/semanticTagService.js 
  ?language=<%= userLocale %>" ></script>

  After updating the JSPF file, enter the following command to make the changes effective:

  touch Default.jsp

  As an alternative, you can edit (open and save) Default.jsp.

• If you created themes with a left navigation menu in a previous version, these themes will not work in the current version because they do not have the plus (+) sign next to the page to expand the node. To ensure that such themes function correctly, change the value of navigation.expansion.defaultstate to true in WP ConfigService provider. For more information, see Setting service configuration properties.

• If you migrate a portal page from v6.0.1.x to V7.0 and the migrated page includes a v6.0.1.x icon for its page label, the icon for the page label might not render in the target environment as a result of changes to handling of page metadata starting in V6.1:

  • When page metadata is retrieved, if the parameter resides in the page but has no assigned value, an empty string is returned instead of a null value.

  • When labels or pages are created, the pageIcon metadata parameter is not included by default; instead, it is included only if a value is set.

  Because of these changes, migrated themes may require additional adjustment to check for an empty string in addition to a null value. In the sample snippet below, the code that checks for an empty string looks like this:

  if(pageIcon != null && !pageIcon.toString().equals(""))

    <portal-navigation:navigation startLevel="${themePolicy.rootNavigationStartLevel}" 
     stopLevel="${themePolicy.rootNavigationStopLevel}">
      <portal-navigation:navigationLoop>
      if (wpsNavNode instanceof com.ibm.portal.MetaDataProvider) {
        com.ibm.portal.MetaData iMetaData  = ((com.ibm.portal.MetaDataProvider) wpsNavNode).getMetaData();
        ...
        //theme relative path to page icon is stored in page metadata
        Object pageIcon = iMetaData.getValue("com.ibm.portal.PageIcon");
        if(pageIcon != null && !pageIcon.toString().equals("")){%>
          <c:set var="pageIconUrl" >
            <portal-logic:urlFindInTheme file='<%=pageIcon.toString()%>' />
           </c:set>	
        <%}else{%>
          <c:set var="pageIconUrl" >
          </c:set>	
        <%}
       }
       ...
      </portal-navigation:navigationLoop>
    </portal-navigation:navigation>

• In WebSphere Portal v7.0, the V7.0 Portal theme must be used with the administrative portlets. The administration page is marked with the unique name wps.administration, and pages under this node are set to the V7.0 Portal theme.
  When you migrate from an earlier version of WebSphere Portal, the old Administration pages are never migrated forward. Virtual portals are treated differently, however, and their administration pages are migrated. If the virtual portal's administration pages are under the wps.administration node, WebSphere Portal migration automatically sets these pages to the V7.0 Portal theme. However, if the virtual portal's administration pages are not under the wps.administration node, migration does not set them to the V7.0 Portal theme. You must do this manually by using xmlaccess.sh. For example:

  <request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    type="update" xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd">
    <portal action="locate">
      <skin action="locate" domain="rel" objectid="ibm.portal.skin.IBM" 
       uniquename="ibm.portal.skin.IBM"/>
      <skin action="locate" domain="rel" objectid="wps.skin.noSkin" 
       uniquename="wps.skin.noSkin"/>
      <theme action="locate" domain="rel" objectid="ibm.portal.theme.Portal" 
       uniquename="ibm.portal.theme.Portal"/>
      <content-node action="update" active="true" domain="rel" 
       objectid="wps.Administration" themeref="ibm.portal.theme.Portal" 
       type="label" uniquename="<Your admin page unique name>"/>
    </portal>
  </request>

  For more information, see the XML configuration reference topic.

• Migration does not upgrade themes from an earlier version to use new functionality that has been introduced in more recent versions of the product.

Changes that you make to migrated themes in the local file system are not automatically applied to the portal's master configuration. The preferred way to update themes is to extract and expand the MigratedThemes.ear file, make the required updates, and then repackage and redeploy the updated EAR file. For an example of how this is done, refer to the Update custom themes and skins to remove hardcoded context root references topic.

Parent

Migrate v6.0.1.x customized resources

Related tasks

Update custom themes and skins to remove hardcoded context root references
Set service configuration properties
XML configuration reference

Implementing a single level of navigation

 

+

Search Tips   |   Advanced Search