Skip to content

Hints and tips for working with virtual portals

View information about configuring virtual portals, hints and tips, and known limitations in HCL Digital Experience (DX).

  • Do not grant the sub-administrators of virtual portals the access permissions to run any installation-related tasks, such as installation of portlets or themes. The isolation between the different virtual portals as provided by HCL DX 8.5 is limited to some extent. All virtual portals share a common Java virtual machine (JVM). Therefore, it is important to restrict the administration privileges of the virtual portal sub-administrators and prevent them from installing their own code artifacts, such as themes or portlets. Unstable or malicious code that is introduced on one virtual portal can destabilize the entire portal installation and all other virtual portals. A flexible way to introduce virtual portal-specific portlets without impacting any other virtual portals is to use Web Services for Remote Portlets (WSRP). For more information about WSRP, go to Using WSRP services.
  • Not all resources can be scoped to individual virtual portals. For example, all themes and skins are available to all virtual portals without restrictions. Credential vault, portlet services, and portal services are also common for an entire portal installation. They cannot be scoped to an individual virtual portal.
  • The settings that are defined in the portal property files apply for the entire portal installation. You cannot specify separate settings for individual virtual portals.
  • If you want to use the single sign on feature that is provided by WebSphere® Application Server, you must use the same common domain suffix for all virtual portals.
  • Portal search, personalization, and templates, are not aware of virtual portals.
  • There are no virtual portal-specific enhancements to the published portal commands and application programming interfaces.
  • A URL mapping or friendly URL that is defined for a resource in a particular virtual portal must use the same URL context as the human readable URL context for that virtual portal itself. Example: In a virtual portal that uses the human readable URL mapping wps/portal/vp_1, all URL mappings or friendly URLs for portal resources must start with wps/portal/vp_1, for example wps/portal/vp_1/url_1 and wps/portal/vp_1/url_2. Within this virtual portal, a URL mapping or friendly URL such as wps/portal/url_1 is not valid, as the portion vp_1 of the URL Context is missing.
  • The administration portlet Virtual Portal Manager cannot delete all resources that are associated with a virtual portal. For example, it does not delete extra URL mappings that administrators created for the virtual portal. You can use the XML configuration interface to delete the URL mappings.
  • All virtual portals on a portal installation share a common logging and tracing.
  • When you reinitialize a virtual portal by using the Virtual Portal Manager portlet, this applies the XML script for the default virtual portal content (or your custom script) again and re-creates the default content of the virtual portal. Resources that you removed from the default content are re-created. Resources that you added to the default content remain in the virtual portal.
  • You must run the wp-create-realm task to create realms for your virtual portal. See the topics about Realm support and about adding realm support file for your operating system.

  • The Portal Access Control administration in the Resource Permissions portlet shows users from different realms who have role mappings on shared resources by their object IDs. Therefore, apply special care and consideration when you are deleting such portal resources: Do not delete resources on which users from other realms have role mappings, if they are required in other virtual portals. This applies to members of roles on portal resources that cannot be scoped and are therefore shared between the virtual portals. Role members who belong to the realm of your local virtual portal are displayed as usual, but role members who belong to different realms are displayed in a different manner:

    • Role members for shared resources who belong to the virtual portal that you are currently working are listed by their actual names under which they were created.
    • Role members for shared resources that do not belong to the realm of the current portal are listed by their portal object IDs. For example, a role member from a different realm might be represented as 8_0_B. Find the list of role members. Click the Administration menu icon. Then, click Access > Resource Permissions..From the list of Resource Types, select a Resource Type by clicking it. On the Resource Permissions page, click on the Assign Access icon. The members are listed in the Roles column.

  • You cannot create custom URLs in one virtual portal that address portal resource in another virtual portal. The reason is that both object IDs and unique names relate to resources of the local virtual portal.