5 Obsolete Features and Usage Changes

5.1.1 URL Portlet and XML Portlet

The URL Portlet and XML Portlet features, that were used to create new portlets in earlier releases of OracleAS Portal, are now deprecated. The Web Clipping and OmniPortlet features replace the functions of URL Portlet and XML Portlet respectively. You can create new portlets by using Web Clipping or OmniPortlet from the Portlet Builder folder in the portlet repository. Existing URL Portlet and XML Portlet instances on your pages will continue to function as in previous releases.

5.1.2 User Interface Templates

In earlier releases, unstructured UI templates governed what was displayed around the page. From release 10.1.4 onward, HTML page skins replace the functions of unstructured UI templates. After an upgrade, unstructured UI templates that were created before release 10.1.4 will be available for use as HTML page skins in the Shared Objects page group.

5.1.3 Obsolete Substitution Tags for HTML Templates

The following substitution tags for HTML templates are obsolete from OracleAS Portal release 10.1.4 onward:

• PAGE.STYLE.URL

• PAGE.BGIMAGE

• PAGE.BGCOLOR

• PAGE.SUBPAGELINKS

It is recommended that you delete these obsolete substitution tags if they are still available in HTML templates. For information about deleting these tags, refer to Section 4.1.2, "Removing Obsolete Substitution Tags in HTML Page Skins".

5.2.1 Introduction of the HTML Output Compatibility Mode Switch

Many of the elements on a portal page are defined by text attributes, entered either by the page designer or the user. Along with text, it is also possible to enter HTML tags and expect them to be rendered on the page.

For example, you can enter the following in the page title:

<b>OracleAS 10<i>g</i> Collateral</b>

And expect it to be rendered as follows:

OracleAS 10g Collateral

However, this poses a security risk as anything can be entered into the element, including JavaScript.

For pages and portlets generated by using PL/SQL, OracleAS Portal release 10.1.4 introduces a compatibility mode that lets you choose whether elements with HTML tags are rendered in the browser, or the HTML tags are filtered out and displayed as text on the page thereby eliminating the security risk.

Some fields are purposely intended to contain arbitrary HTML provided by the end user, as this data cannot be filtered without compromising the usefulness of the feature itself. These components are not affected by the compatibility mode and are therefore never filtered. Components of this type include HTML Portlet, Rich Text Item, and HTML Page Skins.

However, if required, it is also possible to switch off the use of the HTML Portlet by deleting it from the portlet repository. The use of the Rich Text Editor to edit text items can be turned off at the page group level so that users can enter only plain text in text items. And, to restrict the access to HTML Page Skins, developer privileges can be granted to a small set of users only.

When upgrading a portal instance, the compatibility mode is disabled by default after the upgrade. This means that HTML tags are filtered out. Therefore, after upgrade, on systems that have leveraged HTML tags, you will find that the appearance of some pages has changed. This is because the HTML tags are displayed as text. To remedy this situation, you can either remove the HTML tags, reverting to the default portal functionality, or enable the compatibility mode by performing the tasks described in the following sections.

For any pages and portlets generated by using PL/SQL coding, the compatibility mode switch includes two packages, cfgcmyes.pkb and cfgcmno.pkb, to turn compatibility mode on and off respectively.

Running the cfgcmyes.pkb package turns compatibility mode on. As a result of this, HTML tags are not filtered but are allowed to be rendered by the browser. This is equivalent to the behavior in prior releases.

Running the cfgcmno.pkb package turns compatibility mode off. As a result of this, HTML tags are filtered out and appear as text.

To enable compatibility mode:

1. Navigate to the CD_ROOT/portal/admin/plsql/wwc directory.

2. Log in to SQL*Plus with the appropriate user name and password for the portal schema. For example:

   sqlplus portal/SE3bJg@orcl123
   
   

3. Enter the following command:

   SQL> @cfgcmyes.pkb
   
   

To disable compatibility mode, perform the same steps 1 through 3, but in step 3, enter the following command:

SQL> @cfgcmno.pkb

5.2.2 URL Changes

Path-based URLs and durable URLs are the two distinct types of URLs used for accessing objects in OracleAS Portal release 10.1.4. In analyzing links and bookmarks to pages on your site, determine the appropriate format for all future manually created links to OracleAS Portal pages.

Due to architectural changes in OracleAS Portal release 10.1.4, many URLs are formatted differently now.

5.2.3 Changes in Caching

In this release, substantial architectural changes were made in caching in order to improve performance and scalability. There is now more granular caching of components of a page that enables variations of caching options for each component. In particular, tab headings, subpage regions, page portlets, and navigation page portlets are now cached separately from the rest of the page definition. This flexibility allows more components to be cached at system level. This was not feasible in earlier releases.

This also allows more fine-grained invalidation, which increases the cache hit ratio and reduces the time to regenerate invalidated content. For example, adding a subpage to a page with a subpage region no longer invalidates the whole page. Instead, it invalidates just the content for the subpage region. Regenerating this content is less expensive than regenerating the whole page.

In general, these caching changes do not result in any functional change. The exception is for pages that contain tabs or subpage regions where the page definition only is cached at system level. In earlier releases, the tabs and subpage display items were cached as part of the page definition, and therefore, they were cached at the system level. As system level caching results in only one cached copy for all users, all users must see the same content. As a result, in system cached pages, all tabs and subpages were displayed to all users viewing the page, regardless of privileges on the tabs or subpages. The security check was applied when the user accessed the tab or subpage. In release 10.1.4, the tab headings and subpage regions are cached at the user level, separate from the page definition, which is cached at system level. Therefore, a page where the page definition only is cached at system level will now display only the tabs and subpages to which the user has access.

While the caching changes in release 10.1.4 allow performance and scalability to be improved by increased use of system level caching, this is not available automatically on upgrade. To ensure improved performance and scalability, the caching options for pages and portlet instances must be manually updated to their optimal settings.

5.2.4 Change in Portal Service Monitoring Link

In earlier releases, the Portal Service Monitoring link would take you directly to the OracleAS Portal Monitoring page in the Application Server Control Console. From release 10.1.4 onward, this link takes you to the highest level Application Server Control Console Farm page. To access the OracleAS Portal Monitoring page, select the Application Server that is servicing the portal instance you want to monitor, and then select the portal target within.