Blog

Oracle Webcenter Sites' vanity URLs have quickly become one of the most popular features in this product.

Multiple clients have already benefited from this feature significantly, but they've also had to struggle as bugs and shortcomings impacted their respective projects.

In the years we've been assessing clients on the use of OWCS, we've found frustration in many cases, derived from their not being aware not only of the existance of those flaws but, more importantly, the impact they have on the technical solutions they've implemented around their websites' business requirements.

We've also observed that some of this frustration frequently arises from these product defects being already documented as part of OWCS' release notes (e.g. the patches'). With the possible exception of only one of the issues listed below, Oracle has already released a patch for all of them already.

For all of this, we've decided to write down a few lines on the known product defects as per latest Patch's Release Notes and briefly illustrate their impact.

We hope this will not stop you from using the vanity URLs feature - it's still a GREAT feature! - but, on the contrary, encourage your (installing the latest patch and) using it with full awareness of what that entails.

Scope

We won't be providing here an exhaustive list of side-effects for each defect here, but just an example of how some of these could impact your website. In some cases, the impact is so obvious it doesn't really add any value providing an example.

At the time of writting down this lines, the latest patch available is "Sites 11.1.1.8.0 Patch 12 - Requires Sites 11.1.1.8.0 installed". Our summary will be based on that patch's release notes.

On Patch 12's Related Bug Fixes

#20963472: Vanity URL is not working with wrapper when redirect URL is configured.

Self-explanatory. In case you are using OWCS-driven redirects, this bug alone should make a case for your installing this patch.

#21139197: Failure message is not descriptive when there are conflicting WebReference URLs and property cs.webreference.conflicts is said to FAIL.

When you copy an asset, its vanity URL are also copied.

This is not noticed with the default configuration because duplicate URLs are simply ignored. However, if cs.webreference.conflicts in futuretense.ini is set to _FAIL_, this causes the "asset copy" to fail.

#21791714: Manual Vanity URLs are lost after creating arguments for the template.

Self-explanatory. This bug alone should make a case for your installing this patch.

On Patch 10's Related Bug Fixes

Patch 10 does not comprise any fixes to vanity url-related bugs. Hence, nothing to comment here.

On Patch 9's Related Bug Fixes

Patch 9 does not comprise any fixes to vanity url-related bugs. Hence, nothing to comment here.

On Patch 8's Related Bug Fixes

#19988521: XXXStart and End Dates are not honored when page is rendered using VanityURL.

Future Site Preview (a.k.a. FSP) - i.e. OWCS' ability to render a page as it will look / looked on a future / past date - is another popular feature in OWCS.

For websites relying on FSP, this means, amongst other things, people and search engines indifferently may be able to reach pages that are not meant to be live yet / anymore; for instance, your next generation, Page asset-driven homepage to be launched next Christmas might end up in the open in October.

As a corolary, special care is to be put not to embed links to expired / future assets inside rich text fields (e.g. CKEditor-driven) so to avoid your old (case expired asset) / new (case future asset) page's URL to be rendered.

On Patch 7's Related Bug Fixes

#18794383: Blank page is rendered when attempting to access a page over Remote Satellite Server with a VanityURL that does not exist.

This will obviously hurt SEO, you don't want URLs serving back blank pages but, at the very least, 404s. Moreover, you should design your rendering logic and configure OWCS (and your app server) in such a way that "elegant" HTTP error pages are served back by OWCS whenever needed.

Also, if you know all your (vanity) URLs will follow a well-defined set of patterns (even if not driven strictly by OWCS' vanity url rules / patterns), you are advised to handle invalid URLs that don't fit any of those patterns before you (rewrite and) forward those to OWCS in the first place.

On Patch 6's Related Bug Fixes

#18506512: Updating an embedded link that is rendered using a VanityURL is not flushing the cached page which results in the VanityURL being invalid

Since the page driven by the asset containing the embedded link does not get flushed from the cache, whenever rendered it will still contain the "old" vanity URL of the asset whose URL you modified, i.e. a broken link (in most cases). Note that this affects you regardless of your using FSP or not.

On Patch 5's Related Bug Fixes

Patch 5 does not comprise any fixes to vanity url-related bugs. Hence, nothing to comment here.

On Patch 4's Related Bug Fixes

#17591399: Non ASCII characters are double encoded in Vanity URLs, #17750290: Trailing slash is getting stripped from the vanity URL, #17950206: Vanity URL is not working on the remote satellite server when asset name is specified with spaces.

These 3 bugs as well as other bugs mentioned in patches 1 thru 3 may prevent your vanity URLs from either getting served back properly whenever requested and/or getting rendered properly.

For those who may not be able to install the necessary patches for solving all  vanity URL production issues, the simplest workaround is usually implementing a custom function (Groovy) which ensures all vanity urls are properly generated in accordance to what's known to work in the due OWCS version / patch. However, that will only work for URLs that are auto-generated via pattern. More details on how to implement custom functions can be found in the Official documentation.

For vanity URLs that are manually specified for each asset, you can only ensure the URL gets properly processed by OWCS by either avoiding the problematic characters / patterns / conditions, deploying the due patch or implementing ad-hoc solutions (not advised)

#17614551: Deleting an asset does not delete the dependent webreference.

A "webreference" is, in Layman's terms, the vanity url. Having said that, it is kind of obvious the kind of issues this bug will create.

#17626268: Specifying a webrootname in a render:gettemplateurl tag results in exceptions

This implies your vanity URLs will not get properly rendered when OWCS is "producing" your web page. There is not much (elegant) you can do about this one but install the due patch.

#17631690: Vanity URL returns 404 when using Remote Satellite Server on WebLogic

This means you will not see an issue when testing the content you author (e.g. on your MGMT / STAGING environments, which rarely run on Remote Satellite Server) but it will only explode when you test the due content / URL via Remote Satellite Server.

Make sure you install this patch in case you are using Remote Satellite Server on Weblogic.

#18038394: Redirects are not working with the relative root URL

Self-explanatory. In case you are using OWCS-driven redirects, this bug alone should make a case for your installing this patch.

#18038466: Vanity URL pattern is only generated on second save

Self-explanatory. In case you are using URL patterns, this bug alone should make a case for your installing this patch.

#18050116: Sites fails to send error when a HTTP error code is 404.

Self-explanatory. In case you are doing graceful HTTP error handling / error pages, this bug alone should make a case for your installing this patch

On Patch 3's Related Bug Fixes

Patch 3 does not comprise any fixes to vanity url-related bugs. Hence, nothing to comment here.

On Patch 2's Related Bug Fixes

#17430140: In Vanity URL, pattern using F:Property does not work consistently.

Self-explanatory. In case you cannot deploy patch 2, our advise is implement your own, custom function which deals with this issue.

#17449698: Vanity URL doubles or loses parameter values.

Oracle has released at least a couple of patches already which should have figured out diverse issues preventing OWCS from adequately processing vanity URLs with a query string longer than 1 parameter.

Based on our experiences with multiple clients, there still remain some issues in that arena; hence, you should know this in case you are planning on using vanity URLs for features which usually require query strings with multiple parameters. Typical use case is a search form, but there are others.

On Patch 1's Related Bug Fixes

#16485252: There is no ability to regenerate url for all assets of a given assettype based on a pattern.

A typical scenario for this is:

- Marketing gives you the "definitive" pattern for Page-driven URLs, say "/article/<locale>/<asset's title>.

- You implement the due URL pattern, deploy it on all environments.

- Marketing authors thousands of assets, launches new website.

- After a few months running, Marketing changes their mind and now want those URLs to start with "/posts/" instead of "/article/".

- You modify the existing URL pattern, but you notice your URLs are not updated accordingly. Houston, we've got a problem!  :)

Sadly, even if you install Patch 10 (or Patch 1), you'll still suffer from this. Every time you modify a URL pattern, you must (re-load and) re-save the concerned assets so their corresponding URL gets re-generated with the new pattern.

In other words, this remains a feature to be added to the product, even as of Patch 10.

A NOTE ON A PARTICULAR ISSUE FOR WHICH A PATCH HAS NOT BEEN RELEASED YET