How vanity URLs work
In a new HCL WebSphere Portal v8.5 installation, vanity URL support is enabled. If you upgrade the HCL WebSphere Portal from a previous version to v8.5, vanity URL support is disabled. We can enable and disable vanity URL support as required using a portal configuration task. See Enable vanity URL support. For vanity URLs to work, we must also enable managed pages. If vanity URL support is not enabled and a user tries to access a vanity URL, the portal gives a 404 return code.
Vanity URLs are stored as part of the page data on the Web Content Manager portal page site area. When creating a vanity URL, both the vanity URL and the information for resolving the vanity URL is stored in the Vanity URL property of the portal page site area item. This storage method has the following consequences:
- You manage vanity URLs using the portal toolbar and the Managed Pages features.
Therefore, if to use vanity URLs, Managed Pages must be enabled. The Managed Pages feature is enabled by default in a HCL WebSphere Portal v8.5 installation. If you upgrade the portal from a previous version to v8.5 and want to use vanity URLs, enable Managed Pages.
- Assigning a new vanity URL to a page, or changing or deleting an existing vanity URL in the scope of a project creates a draft of the page.
- To export vanity URL information, you do not use the XML configuration interface (xmlaccess), but the JCR export feature of the portal page site area.
HCL WebSphere Portal provides a vanity URL servlet. It resolves an incoming vanity URL request to the appropriate portal page or content item.
We can assign multiple vanity URLs to a page. A vanity URL can have different locales attached to it.
Vanity URLs are not included in the portal search seedlist. To provide good ranking for the vanity URL pages with search engines, assign friendly names to those pages. The friendly names are listed in the portal search seedlist. To achieve better search rankings, the portal search seedlist does not list the additional Vanity URLs.
If we have virtual portals, the following rules apply:
- We must assign a vanity URL that is unique across all of your virtual portals.
- The host name of the current virtual portal is used as the host name of the vanity URL. If the virtual portal was defined using a context path, the host name of the virtual portal context path is used.
- For a vanity URL in the default virtual portal, the host name of that default virtual portal is used as the host name of the vanity URL.
An example process flow of a business user who works with a vanity URL is as follows:
- You have a shoe shop, and to advertise a shoe promotion sale.
- You have a portal page that has the following friendly URL:
http://hostname:port/wps/portal/home/shoe_promotion_page
- When creating a vanity URL, we define the vanity URL segment. Example: shoe-sale. We can also select from the following options:
- Portal content item: Use this option to specify a content item on the target page for the vanity URL. When a site visitor accesses the vanity URL, the portal shows the site visitor the page with the content item that you specified.
- Locale: For this option to specify a locale for the target page for the vanity URL. When a site visitor accesses the vanity URL, the portal shows the site visitor the page in the language and locale that you specified.
- To advertise the shoe sale, insert the vanity URL segment shoe-sale into the URL, and add a preceding segment vanityurl. The URL now looks as follows:
http://hostname/wps/vanityurl/shoe-sale
This URL is the vanity URL that you pass out in the advertisements for the shoe sale.
- When a user accesses the page using this URL, the portal redirects the user to the shoe sale page under the URL given earlier:
http://hostname:port/wps/portal/home/shoe_promotion_page
When the portal redirects the user, it also adds state information to the URL. For example, this state information includes information about the portal content and the locale as selected when we created the vanity URL in earlier steps.
- We can make the vanity URLs shorter by omitting the portal root context /wps and the string /vanityurl. In this case, use a web server and define a rewrite rule.
http://hostname:port/shoe-sale
When a user accesses this URL, the HTTP server rewrites this URL to the longer URL, and then redirects the user as described before.
Parent topic: Vanity URLsRelated tasks:
Enable vanity URL support
Provide short vanity URLs