UrlResolver.GetUrl() Giving absolute path


Somewhere between the version 7.8 and 7.13.3 the GetUrl() method seems to have gotten changed.

Now if you in your site settings have a host name with a culture set the method will give you a absolute path with protocol and host instead of the relative one.

This is a major problem for us at the moment as the GetUrl method is used all over the place.

Also if you have another host added after the default one in the sitesetting this will be returned.

Is anyone else experience this or is it just us?

Sep 09, 2014 16:02

Yes, I have seen this changed behaivour too if you have a culture specified on a hostname.

I also noticed that the order you speciify the hostnames apears to matter. Bad if it is correct, since there is no user interface to adjust which host name is the primary host name for a culture. :(

I think the behaoivor is inconsistent and a little bit unpredictable at the moment.

Sep 09, 2014 20:44

Yes, there has been changes around this due to bugs and new (or actually old from CMS6 reimplemented) feature that the link dialog supports language selection.

The bug that this target is http://world.episerver.com/Documentation/Release-Notes/ReleaseNote/?releaseNoteId=116007

As it works now is that during link creation when a language is choosen it will check if there is a host mapped to the language, if so that host is used instead of a language segment. It also checks if current host has the same language mapping then no host switching is done.

Previously if you had e.g. a host like "mysite.com" mapped to "en" and "mysite.se" mapped to "se". Then if a link to the english version of a page was created from the swedish site the outgoing url would look like "/en/page" (which in browser would appear as "http://mysite.se/en/page") with the new behaviour this will instead appear as "http://mysite.com/page"

@Fredrik: I agree that we probably should introduce a way to sort the hosts. Now you need to remove and add them in a specific order...

I have seen some previous thread where their issue was solved by adding a language mapping (e.g. "en") for wildcard host "*". I am not sure if that would solve your issue since I dont fully understand your case.

Sep 10, 2014 9:43

Thanks for the update Johan.

Our setup is a full Swedish site with four hostnames all going to culture sv say:





Where www.Foo.se is the one set as default in application settings.

The issue we are getting is that we in many places use the following code:

var url = string.Format("{0}{1}", SiteDefinition.Current.SiteUrl, resolver.GetUrl(ContentRefForBar).TrimStart(new[] { '/' }));

And before the update this would give us http://www.Foo.se/bar

But now we get http://www.Foo.sehttp://Foo.se/bar

So it seems the GetUrl gives us a absolut path instead of just the relative /bar one. 

The first workaround that we are currently using is to remove the foo.se from site settings. This helps remove the problem with double login screens for edit/admin but we still get the link issue on our sitemaps and other places. But now with the double http://www.Foo.se.

I'm deploying a workround for our customer tomorrow where I remove the Sitedefinition stuff on the places we have determened critical but would be grand to get a more permanent solution.

Got a support case running and got a bug registered for tomorrow's triage so keep an eye out for (#117292) =)

Sep 10, 2014 11:09

Hmm, so you mean you have language map to "sv" for all hosts in "Manage WebSites" in admin mode?

Then it should stay on current host given that current host is any of those hosts (with stay I mean it should be a relative Uri).

You could perhaps try to remove all other language mappings and just keep the one for "*".

Sep 10, 2014 11:20

Is there a way to do that?

I can't seem to remove the www.Foo.se one as this is set as Url in the settings. And that filed wont take * as imput. So the deletbutton for www.Foo.se is disabled

Sep 10, 2014 11:32

I do not mean to remove the hosts, just the language mapping for the hosts. That is keep the hosts but remove the languages for them.

Sep 10, 2014 11:33

Hmm well I was able to delete the * and recreate it so it's first in the list. Initial testing shows it seems to do the trick for now. 

Sep 10, 2014 11:36

Removing the languages from them seems to work to but would give me a new issue with /sv beeing added to urls

Sep 10, 2014 11:40

If you goto admin mode and under Manage web sites languages change so only "sv" is enabled (you might need to restart the site before you see any effect, I recall some bug about settings being cached), you should get rid of the lang segment.

But I think it should work to have language "sv" mapped for each host as well... 

Sep 10, 2014 11:52
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.