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

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

If you have developed custom themes or skins containing hardcoded references to the portal's context root, this can cause problems if the context root is changed. This is particularly an issue after migration because the context root is modified during migration, causing hardcoded references to break. Rather than modifying your custom themes and skins manually each time you change the context root, we can update the themes and skins to remove the hardcoded references and instead use dynamic references that work properly regardless of the context root.
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. By starting with MigratedThemes.ear and modifying the themes and skins, we can then deploy the new EAR and make the updated themes and skins available to the portal.
Extract the MigratedThemes EAR from IBM WebSphere Application Server using the WAS admin console.

Expand the EAR to a directory using...
PROFILE_ROOT/bin/EARExpander.sh

Update the custom themes and skins to remove any hardcoded references to the original context root. Theme and skin artifacts that could have a hardcoded path include links to JavaScript files, CSS files, or other JSP files.

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="http://setgetweb.com/p/portal80//wps/themes/html/ThemeName/css/SomeStyles.css" type="text/css" />

<link rel="styleSheet" href="http://setgetweb.com/p/portal80//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>
We can change the context root for the themes and skins application by modifying the application.xml file for the EAR. We can also update the display name for the application and WAR name 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>/wps</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>
After updating the application.xml file, repackage the EAR, and deploy the EAR in WAS using the WAS admin console.
If you intend to reuse the original context root for the migrated portal, remove the MigratedThemes.ear application generated during migration.

Manually synchronize the nodes.

Log on to the IBM WAS using the WAS admin console.

Click System Administration > Nodes.

Select the nodes to synchronize, and click Synchronize.
To make the updated themes and skins available on the new context root, update the portal configuration for any themes and skins referencing the old context root.
Export the themes and skins using xmlaccess.sh.
For example, create an XML input file containing the following request and submit it using the xmlaccess command:
<request
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="PortalConfig_8.0.0.xsd"
    type="export">

    
    <portal action="locate">            <skin action="export" objectid="*"/>
  <theme action="export" objectid="*"/>
    </portal>
</request>
Example command:
WP_PROFILE/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_foo
The output file generated from the xmlaccess command contains the themes and skins defined in the portal.
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.

Update <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">

Update <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">

After completing the updates to the output file, we can use the file to re-import the changes to the portal with the xmlaccess command.
After all hardcoded references to the old context root have been removed and the updated themes and skins have been made available in the portal, we can change the portal context root.
Parent: Migrate from WebSphere Portal V6.1.x on a V6.1 application server
Related:
Change the portal URI