Oracle® Fusion Middleware Technical Reference Guide for Site Studio 11g Release 1 (11.1.1) E10615-02 |
|
![]() Previous |
![]() Next |
This section covers the following topics:
If you are upgrading from a Site Studio release before 7.5, you must upgrade your web sites before you can use them with Site Studio 11gR1. This is because Site Studio versions 7.5 and 10gR3 have some important architectural changes, including:
The site hierarchy is stored in a project file and no longer relies on folders. As a result, Oracle Content Server's folders features are no longer required.
The web site URLs display as a logical path and suffix instead of as a CGI-based address displaying the SS_GET_PAGE service (see Section 11.7.38, "SS_GET_PAGE" ). As a result, you see friendlier, path-based URLs.
Layout pages no longer use the <base> tag. Therefore, hyperlinks and references that rely on the base tag must be modified.
The siteId and root node id are no longer synonymous.
It is important to realize that, after upgrading, the upgraded projects will work as "legacy" projects in Site Studio 11gR1; that is, they will use the pre-10gR4 architecture and they will not take advantage of the new architecture and features in Site Studio 10gR4 and 11gR1. The same is true of projects that were created using Site Studio 7.5 or 10gR3. They do not need to be upgraded per se and you can use them with Site Studio 11gR1, but they will continue to function in "legacy" (that is, pre-10gR4) mode.
When you upgrade your pre-7.5 Site Studio release and your web sites, the following tasks are performed automatically:
Action | Description |
---|---|
Folders-based sites upgraded to project-based sites | The existing hierarchy in the folder structure is reproduced in the project file. The root "dCollectionName" is used as the "siteLabel," the root "dCollectionID" is used as the "siteId," the "originalCollectionID" project attribute is set, and the site type is transferred from the root section to the project. |
Custom section properties in new sites updated | The custom section properties of type "siteid" and "url" are updated (adding friendly URLs, where necessary). |
Fragment instance parameters in layout pages updated | Parameters of type "managedurl" and "url" are updated. |
Metadata populated | If the Create Project Files option is enabled, the "xWebsiteSection" values are populated (derived from "xCollectionID"). |
Links in layout pages and data files updated | If the Upgrade Layouts and Upgrade Data Files options are enabled, the weblayout links in layout pages and contributor data files are updated to include the HttpRelativeWebRoot token; optionally, the javascript links are updated. |
Navigation updated | The navigation files for the web site are regenerated. |
Note: Custom elements cannot be upgraded automatically. For more information, see Section B.4.4, "Updating Your Custom Elements." |
The task of site upgrade begins with upgrading the Site Studio component on each of the content servers you are using, and then upgrading the web sites stored on the content servers:
Section B.3.1, "Upgrading Sites on a Single Content Server Instance"
Section B.3.2, "Upgrading Sites on Multiple Content Server Instances"
Although the Folders component is not used in Site Studio version 7.5 or later, you must retain folders during the upgrade of your web sites so that each site can be migrated from a folders-based hierarchy to a project-based hierarchy.
You can then disable the Folders component. If you want to continue using Folders, you must configure them with the appropriate metadata (see Section B.4.5, "Assigning a Web Site Section to Your Folders").
Note: When you follow the upgrade steps, every web site on the server is upgraded. If you want to upgrade only selected sites, then you must create a copy of the other sites on another server. |
If your web sites are stored on a single content server, the upgrade consists of:
Installing the new Site Studio component (having first uninstalled the old component).
Performing a full upgrade on the content server. For more information, see Section B.3.3, "Performing a Full Upgrade."
Performing additional steps manually that are not handled by the automated upgrade. For more information, see Section B.4, "Performing Additional Steps Manually."
You may have sites on multiple content servers, each serving a different purpose, such as a development server, a contribution server, and a production server.
Figure B-1 Multiple Content Server Instance Illustration
The content on each server (source server) gets copied to the next server (target server) using the Archiver/Replicator utility. As such, it is important to carefully plan and upgrade the sites on each server without encountering replication problems.
On the First Two Instances of the Content Server
Stop replication between the content servers.
Install the new Site Studio component.
On the Source Instance of the Content Server
Perform a full upgrade of your sites. For more information, see Section B.3.3, "Performing a Full Upgrade."
Then:
Perform additional steps manually (steps not handled by the automatic upgrade). For more information, see Section B.4, "Performing Additional Steps Manually."
On the Target Instance of the Content Server
Perform a minimal upgrade of your sites. For more information, see Section B.3.4, "Performing a Minimal Upgrade."
On Both Instances of the Content Server
Start replication again between the content servers.
Once the new component has been installed on all instances of the content server and web sites have been upgraded as indicated above, you can begin replicating your sites again.
You can use the replication feature in Site Studio (see the Oracle Fusion Middleware Administrator and Manager's Guide for Site Studio). Or, if you have been using Archiver/Replicator and want to continue using it, you can do so as long as you modify the archive query to include Site Studio project files.
On the Next Target Content Server (Downstream in Replication)
Stop replication between the source and target content servers.
Note: In this case, your source server (Box 2) was the target server in the previous steps, and your target server (Box 3) is the next server down the line (downstream) in your replication. |
Install the new Site Studio component.
Then:
Perform a minimal upgrade of your sites. For more information, see Section B.3.4, "Performing a Minimal Upgrade."
Then:
Start replication again between the source and target content servers.
Repeat this last procedure for each target instance of the content server downstream in your replication.
A full upgrade of the content server is required in the case of single-server setup. It is also required for the source server in the case of a multi-server setup. (All other servers in a multi-server setup require a minimal upgrade.)
When you upgrade your site, Site Studio turns your existing folder-based site into a project-based site. When it does this, it creates a project file as a managed item in the content server. As such, you must identify the metadata that you would like assigned to the project file that will represent each web site.
During the upgrade process, the content server attempts to index content that gets changed, which could take considerable time and resources. You may want to temporarily disable automatic indexing before you begin the upgrade process and then re-enable it when you are done. (See the Oracle Content Server administration documentation for further details.)
You should have already installed and enabled the new Site Studio component on the server before you start a full upgrade.
To perform a full upgrade, perform these tasks:
Log on to the content server as an administrator, open the Administration page, and then the Site Studio Administration page.
Click Set Project Default Document Information.
The Set Project Default Document Information page opens. This is where you assign the default metadata for the new projects that you create in Site Studio.
Once you have specified the metadata values, click Update.
This returns you to the Site Studio Administration page, where you can begin the upgrade process.
Click Manage Web Sites.
Click Go to Web Sites Update Page. (This option displays only when older web sites are detected.)
Click Advanced Options to specify site upgrade options.
Figure B-2 Advanced Upgrade Options Screen
Choose the following for a full upgrade:
Select Create Project files.
Select Upgrade Layouts.
Select Upgrade Data Files.
Select Convert Hyperlinks and choose a link format:
To Server-Side Links: Links contain the coded identity of the target location using server-side script.
To Path-Based URLs: Links contain the full path to the target location.
Click Set Options to return to the Upgrade Legacy Web Sites page.
Click Start Upgrade.
You see the individual files that must be upgraded on this page. Wait until you see the message that says that the upgrade process was completed.
Note: The site upgrade automatically updates the site hierarchy and its many links, and the Web Sites menu in the content server now lists your sites. |
A minimal upgrade is required in the case of a multi-server setup and applies to all target servers; that is, the server that has web sites being replicated to it.
You should have already installed and enabled the new Site Studio component on the server before you start a minimal upgrade.
To perform a minimal upgrade, perform these tasks:
Log onto the content server as an administrator, open the Administration page, and then the Site Studio Administration page.
Click Set Default Project Document Information.
The Set Project Default Document Information page opens. This is where you assign the default metadata for the new projects that you create in Site Studio.
Once you have specified the metadata values, click Update.
This returns you to the Site Studio Administration page, where you can begin the upgrade process.
Click Manage Web Sites.
Click Go to Web Sites Update Page. (This option displays only when older web sites are detected.)
Click Advanced Options to specify site upgrade options (Figure B-2).
Select Create Project files.
Note: This upgrades project files and populates the "Web Site Section" metadata value. |
Click Set Options to return to the Upgrade Legacy Web Sites page.
Click Start Upgrade.
Wait until you see the message that says that the upgrade process was completed.
The Web Sites menu in the content server now lists your sites.
Once you have upgraded your web sites, there are still several steps that you must perform manually, including the following:
After upgrading a pre-7.5 web site, you must update its navigation files. You can do this in Designer (using the Update Navigation button) or on the Site Studio Administration page (specifically, the Manage Web Sites page). This step is necessary for Contributor to function correctly on the site.
After upgrading a pre-7.5 web site, you may need to rebuild the content server index. If your content server has been set up to use database search and indexing (full-text or metadata-only), you do not need to rebuild the search index. If you are using a different search engine, you must rebuild the search index. This is necessary because Site Studio updates the xWebsiteSection metadata field for all content items residing in folders on your site.
Caution: Rebuilding the search index may be a very time-consuming process, depending on the number of content items managed by your Oracle Content Server instance. It is therefore recommended that you perform this rebuild during off-peak hours of Oracle Content Server use (typically at night or on the weekend). |
See the Oracle Content Server administration documentation for more information on rebuilding the index.
Most of the manual updates you must perform after upgrading your pre-7.5 web site involve modifying your custom fragments. If you are currently using the predefined fragments that came with Site Studio, you do not have to do this because an updated version of each fragment is included with each Site Studio release.
Most likely, you have customized the fragments or introduced new ones to meet a specific purpose for your organization. There are three things you must do with the fragments so that they work in the latest version:
Section B.4.3.1, "Modifying Links That Rely on the <base> Tag"
Section B.4.3.2, "Modifying Obsolete SS_GET_PAGE / JavaScript Links"
The <base> tag that points to the content server's web-accessible directory ('weblayout') is no longer used. During the site upgrade, Site Studio updates the necessary code in your layout pages and contributor data files, but you must perform this step manually in your custom fragments and scripts.
You can do this by re-authoring hand-coded links that are relative to the URL in the <base> tag and use the HttpRelativeWebRoot server-side variable instead.
Example
Say, you have a link to a graphic that looks something like this:
<img src="groups/public/documents/adacct/logo.gif">
You must then replace it with the following:
<img src="<!--$HttpRelativeWebRoot-->groups/public/documents/adacct/logo.gif">
If any existing fragments use SS_GET_PAGE, javascript:link, or javascript:nodelink style hyperlinks, you may want to change them to path-based URLs to take advantage of their many benefits. (For more information, see the Oracle Fusion Middleware User's Guide for Site Studio Designer.)
Example
Consider a link that looks something like this:
<a href="javascript:nodelink(42);">link</a>
It must be replaced with the following:
<a href="<!--ssServerRelativeSiteRoot-->products/servers/index.htm">link</a>
Any fragment that used the GET_SEARCH_RESULTS service will continue to work, but will not take advantage of the features provided by Site Studio 7.5 and 10gR3 until it is upgraded to use the SS_GET_SEARCH_RESULTS service (for more information, see Section 11.7.43, "SS_GET_SEARCH_RESULTS") .
Using the SS_GET_SEARCH_RESULTS service has several advantages:
limitscope logic (now provided by the service and not required in the fragment): This limits the search results to only those items within the current web site.
dontshowinlists logic (now provided by the service and not required in the fragment): This limits the search results to only those items that have not been removed from lists by contributors.
ssUrl: This column provides a friendly URL for each row in the search results.
Fragments that use the GET_SEARCH_RESULTS service are typically dynamic list fragments and search results navigation fragments. The updates required differ depending on the version of the Site Studio release that you are upgrading from:
If you have been using Site Studio version 6.5, and you have customized dynamic lists or search results fragments using that version (for example, by copying a Site Studio fragment and adding custom code to it), you will have used code that performs limitscope logic using the old xWebsiteID metadata field.
If you have been using Site Studio version 7.2, and you have customized dynamic lists or search results fragments using that version (for example, by copying a Site Studio fragment and adding custom code to it), you will have used code that performs limitscope logic using the new xWebsites metadata field. In addition, you will have used code that performs dontshowinlists logic using the new xDontShowInListsForWebsites metadata field.
In both cases above, you must update those fragments to remove the old limitscope and dontshowinlists logic from them and to use the new SS_GET_SEARCH_RESULTS service, which now provides this functionality internally.
Example
In Site Studio 6.5, the Standard Dynamic List fragment includes the following code for the SSLimitScope parameter. This should be removed:
<!--$QueryText=eval(ssQueryText)--> <!--$if ssLimitScope like "true"--> <!--$if strEquals(QueryText, '')--> <!--$QueryText='xWebSiteID=' & siteId--> <!--$else--> <!--$QueryText='(' & QueryText & ') and (xWebSiteID=' & siteId & ')'--> <!--$endif--> <!--$endif-->
In Site Studio 7.2, the Standard Dynamic List fragment includes the following code for the SSLimitScope parameter. This should be removed:
<!--$QueryText=eval(ssQueryText)--> <!--$if ssLimitScope like "true"--> <!--$if strEquals(QueryText, '')--> <!--$QueryText='xWebsites <contains> ' & siteId--> <!--$else--> <!--$QueryText='(' & QueryText & ') and (xWebsites <contains>' & siteId & ')'--> <!--$endif--> <!--$endif--> <!--$if strEquals(QueryText, '')--> <!--$QueryText= 'not(xDontShowInListsForWebsites <contains> ' & siteId & ')'--> <!--$else--> <!--$QueryText='(' & QueryText & ') and not(xDontShowInListsForWebsites <contains> ' & siteId & ')'--> <!--$endif-->
Once the old limitscope logic is removed from the fragment, change the GET_SEARCH_RESULTS service call to use SS_GET_SEARCH_RESULTS. Before you invoke the SS_GET_SEARCH_RESULTS service, however, you should set the following parameter values:
Parameter | Description |
---|---|
ssLimitScope | Specifies that the limitscope logic should be applied by the SS_GET_SEARCH_RESULTS service. Typically this true/false value is supplied by a fragment parameter value. |
ssDontShowInLists | Specifies that the dontshowinlists logic should be applied by the SS_GET_SEARCH_RESULTS service. Typically this true/false value is set to "true" in all fragments. |
ssTargetNodeId | Specifies the node ID that is used to display the search results. The "ssTargetSiteId" can also be used to generate links to other web sites on the content server. If the "ssTargetSiteId" is not specified, the generated link assumes the same site that originated the link. |
ssTargetSiteId | Specifies the site ID that is used to display the search results. The "ssTargetNodeId" parameter must also be used to fully qualify the target node. |
ssSourceNodeId | Indicates the node ID for the current page containing the link. |
ssSourceSiteId | Indicates the site ID for the current page containing the link. |
ssWebsiteObjectType | Specifies that the search results should be limited to a specific Website Object Type. Typically you leave this value empty. |
ssUserSearchText | Specifies any user text to perform a full text search. Typically, this only applies to Search Results fragments where the value is provided by a consumer entering a value in a Search Box fragment. |
When looping through the results of the SS_GET_SEARCH_RESULTS service call, you typically use the new ssUrl column of the result set if you want to create hyperlinks to that item. This ensures that full path-based URLs are used instead of cryptic ID-based URLs.
Additionally, these URLs should be appended with parameters that describe the source location of the link. This allows error pages to be generated properly when there are invalid links.
The following parameters should be affixed to the URLs.
Parameter | Description |
---|---|
ssSourceNodeId | Declares the source node ID. Used to generate friendly URLs if both ssTargetNodeId and xWebsiteSection are blank. |
ssSourceSiteId | Declares the source site ID. This allows the error page to be displayed if the target page cannot be found. |
Here is a simplified example using Idoc script:
<!-- New params for SS_GET_SEARCH_RESULTS --> <!--$ssLimitScope="true"--> <!--$ssDontShowInLists="true"--> <!--$ssTargetNodeId=""--> <!--$ssTargetSiteId=""--> <!--$ssSourceNodeId=nodeId--> <!--$ssSourceSiteId=siteId--> <!--$ssWebsiteObjectType=""--> <!--$ssUserText=""--> <!--$executeService("SS_GET_SEARCH_RESULTS")--> <!--$loop SearchResults--> <a href="<!--$ssUrl-->?ssSourceSiteId=<!--$siteId-->&ssSourceNodeId= <!--nodeId-->"> <!--$dDocTitle--> </a><br><br> <!--$endloop-->
For more details, refer to the dynamic list and search results fragments that are provided with the Site Studio product.
Any custom element forms created using a Site Studio release before 7.5 are not compatible with Site Studio 11gR1. They must be manually upgraded and re-authored. The primary reason for not maintaining backward compatibility is Site Studio's prior dependency on Internet Explorer's proprietary window.external functionality (due to the ActiveX control used for the Contributor). This functionality was removed from Site Studio as a result of the browser-independent, JavaScript-based Contributor application that is used in Site Studio 10gR3 (10.1.3.3.3) and higher.
Site Studio no longer uses the Oracle Content Server folder features (Folders component) to organize and manage your site hierarchy. If a web site created in a Site Studio release before 7.5 is upgraded, content that resides in a folder has a new metadata value (Web Site Section) assigned to it so that it is recognized as part of the upgraded site.
Any new content added to the folder, after the upgrade, will not receive this metadata value. As such, if you want to continue using folders to add content to your site, you must assign a Web Site Section value to each folder.
To assign a Web Site Section value, perform these tasks:
Log onto the content server as a user with write (RW) access to the folder you want to update.
Open the Browse Content tray or menu, and then open the Web Sites tree.
Select the web site to want to update.
Click Folder Information for the folder you want to change.
Select the Update action.
Click Browse next to the Web Site Section field.
Choose the corresponding web site section.
Click OK.
Click Update.
Repeat these steps for each folder that you want to map to a web site section in Site Studio.