Set vanity url for Touch devices

This post is about one of the solution to one of the bugs within Oracle WebCenter Sites 11g 11.1.1.8.0 (any patch): Vanity url generated for desktop does not work on mobile or tablets. Just ignore this post if you are not using WebCenter Sites 11g8 version and/or later.

Whats the issue about?
Suppose you created a site and have created/generated vanity url only for DESKTOP device group and did not bother to create any vanity url for TOUCH devices, then the vanity url which was generated for DESKTOP fails to work on mobile and tablets whereas they work as expected when browsed through desktops. Mobile devices shows long urls which are not at all desirable by any client.

Reason behind the issue?
This behavior is because WebCenter Sites adds one parameter - "d" whenever asset's link is generated via any tags or API and it's a product default behavior. For DESKTOP device group, d's value is null whereas for TOUCH device group, d's value is Touch. As any mobile or tablet receives request to load vanity url, WebCenter Sites set the d parameter to Touch and finds that there is no vanity url, thus, resulting in long non-desired url.

So, what can be done to resolve this? Are there any workaround solutions?
Yes, Oracle has already provided two workaround solutions.

In this post, I have discussed briefly on achieving one of the solution as quickly as possible if your client is in hurry to resolve it. One of the solutions recommended by Oracle is to generate vanity url for all the assets for TOUCH devices and pass the d parameter's value while generating hyperlinks for assets via <render:gettemplateurl> tag. By doing so, now as all your assets will have vanity url for TOUCH devices also, tag will generate correct vanity which will work for mobiles and tablets.

But the problem is: how to create/generate vanity url for so many assets and how to make sure that any new asset which will be created in future will have vanity url for both DESKTOP and TOUCH device group? One cannot just keep on adding vanity url by editing and saving assets for TOUCH device group as there can be very large number of assets.

Plausible solution:
I have thought of a few solutions which may work for many customers. So what can be done? One can think of creating asset listener which will generate vanity url on saving asset but problem of using asset listener is that the custom attributes are not available on event: NEW. This is described in one of my old post. Thus, adding asset listener cannot handle both issues if you are using some custom attribute as a part of vanity url for the asset but following solution can.

Following are 2 ways for generating vanity url for TOUCH device group:

1. First thing is obvious, configure TOUCH device group for your site. For details, check the chapter: Mobility in developer's guide.
2. Either write custom flex filter or call an element from POSTUPDATE which will generate vanity url for TOUCH device group for the asset.
3. If you are calling an element from POSTUPDATE element, add the following code in the called element and update as required. Logic for generating vanity url using flex filter will remain same.
4. Once you are ready with any one of the above, all the old assets are required to edit & saved so vanity url is generated; which can be done either via Support Tools or writing small utility element.
5. For any new asset which would be created in future, flex filter or the element called from POSTUPDATE will take care of it automatically.
6. Update your element/template which generates hyperlink by adding the d parameter in it. Note: d variable is already added to cache criteria so only those templates/elements are required to be updated where logic is present to generate hyperlinks for assets.

Other approaches:

1. If client does not allows for editing & saving all old assets to generate vanity url due any reason for e.g. auditing tasks like capturing who created/updated/approved/published content and when etc., luckily there is solution for it. Create an utility element to generate vanity url directly by updating WebReferences table. WebReferences table holds all the information related to vanity url(s) of all assets. As old assets will have vanity urls, one can find the required params like template, wrapper, etc. from the table itself for DESKTOP device group (note: dgroup column's value will be null for DESKTOP devices) and set vanity urls for TOUCH device group by setting dgroup column's value as Touch. Then you can deploy your new flex filter or the element approach as discussed for new future assets. Very important: Don't forget to take backup of WebReferences table before updating it. Flush resultset cache of WebReferences table after updating it.
2. By creating URL Assembler (old way of generating vanity url) can generate pretty urls if no vanity url is configured. Idea is to generate hyperlinks by assembler if d variable value is Touch else generate hyperlink as usual which would be vanity url. Although according to tag library, if vanity url is present then tag returns vanity url but if d parameter is passed with value "Touch" & no vanity url is configured for Touch device group, then assembler url is generated. This can be pretty quick and neat solution without touching any asset as it is a simple jar file deployed on server and only requires restart after deployment. Also update the logic in your element which generates hyperlink for assets.
3. Although the following suggestion works, it is not good for SEO considering that Google ranks  website on basis of mobile-friendliness also. But still if you want same url for Touch device group also as they are configured for Desktop group, then you can delete all device group except Desktop and restart WebCenter Sites. After doing so, desktop urls will work on mobile or tablet or other phones too.

Disclaimer: This post does not provides full implementation rather just an idea on how to develop such solution. Please note, the code and the configurations posted are not official recommendations and should be used at sole's discretion with proper testing before deploying on live WebCenter Sites systems. Cheers!!