Vulnerability in EPiServer.Forms
We have a customer that wants to have information about both country and language as url segments instead of using sub domains for determining the site. Also, each country should be represented as a separate site in Episerver.
www.customer.com/ca/en/ English version of Canadian web site
www.customer.com/ca/fr/ French version of Canadian web site
www.customer.com/us/en/ English version of US web site
Has anyone done such an implementation in Episerver and if so; how is this implemented? This could be possible if Episerver would allow to include more than just a domain in the site mappings, which does not seem to be allowed right now. We are thinking of using a reverse proxy, but wanted to check the options before investingating that more.
I have done a similar solution for SAS (flysas.com, sas.se, sas.dk, etc) with both market specific and shared content but for Episerver CMS 6 so the solution does not work for newer versions. It uses a subclass of the standard furl module.
I think Electrolux uses custom culture info installed on their windows servers for each market and language combination (like English in Sweden) that does not exist by default to be able to use the built in functionality. That is another way to go.
I would go for having a start page type per market (but without the house) and the real start page is a classic market selector page so you do not violate §3 in EULA. Either the customer accepts that the url is the default host name/lang/market or you will have to be creative and if possible extend/rewrite the custom routes for content (plus simple address) that Episerver installs to change how the language segment is handled. It is probable doable but I have not seen it yet.
You will probably need an additionally market database with info about enabled languages per market, default language per market, what culture info to use for content/ui, but also system culture info for non existing combinations in Windows (like how to sort and format dates when you show English content on the Swedish market).
Easiest is of course to switch language and country segments. Then you don't need to rewrite routing :)
So change requirements to match platform would be my first suggestion. Then use a global start page like Fredrik Haglund suggest above to select market. I've done a few such implementations and so far been able to convince customers to switch requirements to what is supported. Messing with routing is fun but not always well spent money in my opinion... :)
Thanks for the replies. I will surely try and get the customer to weigh any potential business value with the cost and risk of implementing any solution to handle custom routes. Just wanted to make sure that I did not miss anything obvious but it seems that you have the same view as me.
Is there is any solution for this implementation ?