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.

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.

Thanks for the update Johan.

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

Foo.se

www.Foo.se

*

www.bar.se

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) =)

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 "*".

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

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.

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. 

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

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...