Portal V6.1.x on application server V6.1: Updating custom themes and skins to remove hardcoded context root references

Custom themes or skins that contain hardcoded references to the context root can cause problems if the context root is changed. The context root is modified during migration, which causes hardcoded references to break. Update your themes and skins to remove the hardcoded references and instead use dynamic references that work properly regardless of the context root. Once this task is complete you can change the migrated portal's URL from /wps_migrated/portlal to the value used by your migration source server.

About this task

Custom themes and skins in the wps.ear file on the source server are consolidated in the MigratedThemes.ear file on the target server. This EAR file has a context root of /wps, which is why the portal application uses /wps_migrated. Once the context root of this EAR file is changed you can change the portal URI. Start with MigratedThemes.ear and modify the themes and skins. You can then deploy the new EAR and make the updated themes and skins available to the portal.

Procedure

  1. Extract the MigratedThemes EAR from IBM® WebSphere® Application Server. Use the WebSphere Integrated Solutions Console.
  2. Expand the EAR to a directory with the EARExpander command in the was_profile_root/bin directory.
  3. Update the custom themes and skins to remove any hardcoded references to the original context root. Theme and skin artifacts that have a hardcoded path include links to JavaScript files, CSS files, or other JSP files.
    Table 1. Examples of how to remove hardcoded references
    Example Description
    Include statements of other JSP files in the theme can use relative paths. Hardcoded example: <%@ include file="/wps/themes/html/ThemeName/head.jspf" %>

    Corrected example: <%@ include file="./head.jspf" %>

    Links to resources within the theme EAR can be calculated with the findInTheme tag. Hardcoded examples:
    • <link rel="styleSheet" href="/wps/themes/html/ThemeName/css/SomeStyles.css" type="text/css" />
    • <link rel="styleSheet" href="/wps/themes/html/css/SomeStyles.css" type="text/css" />
    Corrected example:
    • <%@ taglib uri="http://www.ibm.com/xmlns/prod/websphere/portal/v6.0/portal-logic" prefix="portal-logic" %>
    • <link rel="styleSheet" href='<portal-logic:urlFindInTheme file="css/SomeStyles.css" />' type="text/css" />
    Links to resources in other EAR files or in a theme with its own EAR file can use server-relative URLs. Hardcoded example: <script type="text/javascript" src="/wps/themes/html/ThemeName/js/ThemeJavascript.js"></script>

    Corrected example after the theme is moved to its own EAR file: <script type="text/javascript" src="/ThemeEarContextRoot/themes/html/ThemeName/js/ThemeJavascript.js""></script>

  4. You can change the context root for the MigratedThemes application by modifying the application.xml file for the EAR. You can also update the display name for the application and WAR name that is associated with the web module. For example:
    <?xml version="1.0" encoding="UTF-8"?>
    <application id="Application_ID" version="1.4" xmlns="http://java.sun.com/xml/ns/j2ee" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/application_1_4.xsd">	
        <display-name>MigratedThemes</display-name> 
          <module id="WebModule_1">
             <web>
                <web-uri>MigratedThemes.war</web-uri>
                <context-root>/MyCompanyTheme</context-root>
             </web>
          </module>
          <security-role id="SecurityRole_1276111387778">
             <description>Everyone in the enterprise.</description>
             <role-name>Everyone Role</role-name>
          </security-role>
          <security-role id="SecurityRole_1276111387779">
             <description>All Authenticated users in the enterprise.</description>
             <role-name>All Role</role-name>
          </security-role>
          <security-role id="SecurityRole_1276111387780">
             <description>No users in the enterprise.</description>
             <role-name>No Role</role-name>
          </security-role>
    </application>
  5. After you update the application.xml file, repackage the EAR, and deploy the EAR in WebSphere Application Server.
    Important: If you intend to reuse the original context root for the migrated portal, you must remove the MigratedThemes.ear application that is generated during migration.
  6. Manually synchronize the nodes.
    1. Log on to the WebSphere Integrated Solutions Console.
    2. Click System Administration > Nodes.
    3. Select the nodes that you want to synchronize, and click Synchronize.
  7. To make the updated themes and skins available, update the portal configuration for any themes and skins that reference the old context root.
    1. Export the themes and skins with the XML configuration interface. For example, create an XML input file that contains the following request and submit it with the xmlaccess command:
      <request
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:noNamespaceSchemaLocation="PortalConfig_8.0.0.xsd"
          type="export">
      
          <!-- sample for exporting skins and themes-->
          <portal action="locate">    
              <skin action="export" objectid="*"/>
      		<theme action="export" objectid="*"/>
          </portal>
      </request>
      Example command:
      wp_profile_root/PortalServer/bin/xmlaccess.sh  -url http://localhost:10039/wps_migrated/config 
      -in request_input_file.xml -out  request_output_file.xml 
      -user portal_admin_id -password portal_admin_password 
      The output file that is generated from the xmlaccess command contains the themes and skins that are defined in the portal.
    2. Edit the output file and update any references to the original context root for themes and skins. The following examples assume that the pre-migrated context root is /wps and the new context root is /MyCompanyTheme.
      Updating <skin> elements
      • Example with old context root:

        <skin action="update" active="true" context-root="/wps" default="true" domain="rel" objectid="ZK_CGAH47L00G1M302N5SU00Q30C2" resourceroot="IBM" type="default" uniquename="ibm.portal.skin.IBM">

      • Example with new context root:

        <skin action="update" active="true" context-root="/MyCompanyTheme" default="true" domain="rel" objectid="ZK_CGAH47L00G1M302N5SU00Q30C2" resourceroot="IBM" type="default" uniquename="ibm.portal.skin.IBM">

      Updating <theme> elements
      • Example with old context root:

        <theme action="update" active="true" context-root="/wps" default="true" defaultskinref="ZK_CGAH47L00G1M302N5SU00Q30C2" domain="rel" objectid="ZJ_CGAH47L00G1M302N5SU00Q3010" resourceroot="Portal" uniquename="ibm.portal.theme.Portal">

      • Example with new context root:

        <theme action="update" active="true" context-root="/MyCompanyTheme" default="true" defaultskinref="ZK_CGAH47L00G1M302N5SU00Q30C2" domain="rel" objectid="ZJ_CGAH47L00G1M302N5SU00Q3010" resourceroot="Portal" uniquename="ibm.portal.theme.Portal">

    3. After you complete the updates to the output file, you can use the file to reimport your changes to the portal with the xmlaccess command.

What to do next

Change the portal URI to a unique name other than wps_migrated. Your migrated portal URI has the following format: http://host_name:port_number/original-context-root_migrated/portal. If you have changed the context root of the MigratedTheme.ear or if MigratedTheme.ear is not installed in your environment then you should set the Portal URI to a format like http://host_name:port_number/original-context-root/portal. For information on how to change the portal URI, see Changing the portal URI.