Hi Magnus,

in one of the docs for the new routing im 4.10 (https://docs.google.com/document/d/19Ids3S57BGnKbGkG-eWACYa0fgTLKiTohsgcOPHBS8Q/edit) I saw that you can now define more types of hostnames:

Umbraco 4.10 supports several types of hostnames:

• Simple hostnames, eg “example.com”;
• Hostnames with a protocol, eg “http://example.com”;
• Hostnames with a port, eg “example.com:81”;
• Hostnames with a path, eg “example.com/english”;
• Any combination of those, eg “http://example.com:81/english”.

Perhaps you should use www.domain.com/en as hostname instead of en.domain.com.

I feel that I will have the same problem when upgrading since I use the same structure for my site...

Hi Magnus,

I just upgraded my multilingual website (en, he) from Umbraco 4.9.1 to 4.10.0 and everything works fine.

I have set up my multilingual structure like this:

en-US (localhost/en-us)

he-IL (localhost/he-il)

greetings,

Anthony

Hi Magnus

What does your setting for <useDomainPrefixes> look like in the umbracoSettings.config file?

/Jan

@Jan the default setting for useDomainPrefixes in my 4.10 nuget-installed was false.

I changed my old "fake" subdomains to using
www.domain.com/en/
www.domain.com/no/    etc...

Same results :(

Then I changed the hostname of one of them to http://localhost:52672/se/ where my IIS Express lives, and presto! The useDomainPrefixes setting started working.

So right now I'm stuck with the urls being:

useDomainPrefixes = true
http://localhost:52672/sv.aspx
http://www.domain.com/fi.aspx

useDomainPrefixes = false
/sv.aspx
http://www.domain.com/fi.aspx

It seems problem could be solved if I change my language-enabling hostnames to http://localhost:port/lang/ and have the prefix to false, but it would not feel good since we would just push this to production server.

Also on the Page properties tab, under Alternative links the url is notated as http://localhost:52672/sv/.aspx ; so it points to a directory and the file .aspx. In reality both /sv/ and /sv.aspx and /sv/.aspx all work when accessed.

I now have the following setup:

Hostnames:

• www.domain.com
• www.domain.com/it
• www.domain.com/de

Hi there. I'm the one who modified the code for this in 4.10... currently reading your posts and will get back to you asap.

If useDomainPrefixes is false then Umbraco should NOT create absolute urls. For the rest... give me a few minutes.

@Magnus: OK, getting back to you.

The correct setting in you case should be useDomainPrefixes set to false and NO bogus domain, and domains like:

• www.domain.com/en -- lang=EN -- note: NO trailing slash, /en not /en/

• www.domain.com/fi -- lang=FI -- note: same

• www.domain.com/sv -- lang=SE -- note: same

Then, the url returned by NiceUrl will depend on the _current_ request. So if you access Umbraco via www.domain.com/umbraco/ and ask for the NiceUrl of a node under your english root then you'll get url "/en/path/to/page" BUT if you access Umbraco via localhost:1234/umbraco/ then you'll get "http://www.domain.com/en/path/to/page" because "localhost:1234" is not declared.

BUT that's only in the back-end, if you browse the website at www.domain.com/en you'll get the right, relative, urls.

I assume if you also declare domain "localhost:1234/en" on the english node, then the urls will be relative in the back-end too...

Does this make things any clearer? If not let me know. Hopefully this will help me clarify & update the documentation.

Hi Stephen,

As far as I can see I'm doing exactly what you described above. But umbraco gives me absolute URLs and also the Culture is always set to English, even on the Page Home-DE. My Content tree looks like this:

Content:

• Site English (hostname: www.domain.com, language: en)
• ------Site Italiano (hostname: www.domain.com/it, language: it)
• ------------Home-IT
• ------Site Deutsch (hostname: www.domain.com/de, language: de)
• ------------Home-DE
• ------Home-EN 

This seems quite strange to me... by the way: useDomainPrefixes is set to false. The node "Site English" has an internal redirect to Home-EN, "Site Italiano" to Home-IT and "Site Deutsch" to Home-DE.

Thanks for your help

Matthias 

@Magnus: and you access Umbraco through www.domain.com/umbraco/, right?

Currently testing your setup...

Hi Stephen,

it seems as if it did not work because I did not include the port in the domain.The webserver is behind a proxy. Although the browser requests www.domain.com, the proxy actually requests www.domain.com:4444 from the webserver.

After including the port in the hostnames, everything works fine now... Umbraco gives me relative URLs and also sets the culture correctly.

Thanks

Matthias 

@Stephen: no I access it currently on IIS express from Visual Studio through http://localhost:port
The project I'm working on is due for release in March so until then the "domain.com" points to the current website.

Working with 4.9.1 here at work and doing the 4.10 experiments at home so I can test more when I get off work. (Well do we ever get off work really? But that is another question lol)

@Matthias: glad it's solved then.

@Magnus: if you access it through http://localhost:port and you configure hostname "www.domain.com" then you'll always get absolute urls, unless you also configure hostname "localhost:port".

I'm currently fighting IIS Express so it serves the test site both on "localhost" _and_ on "dev.domain.com"... driving me mad ;-)

On a node with a single hostname setting http://localhost:55240/en.aspx -> en  it works and I get the NiceUrl  /sv.aspx when accessing the localhost.

But I would also like to have the production setting www.domain.com/en -> en to be added (so it's in there from the start when we later on sync content in steps out to production)

but when I do the localhost version is never used for NiceUrls (on my localhost dev machine). I always get the hard NiceUrl http://www.pax.se/en.aspx
I tried to add these to the node in different order but they always seem to be listed with the www* first. I thought maybe there was some sequence matching to this :-)

@Magnus - no, the sequence order is of no importance, but the fact that you declared "localhost:55240/en" should be picked. That's how we work here. Running tests to figure out what's going on.

I don't know if this of importance...

I'm using the template generated Razor navigation script. I just made sure that @item.NiceUrl is used instead of the default @item.Url for the links.

If I fire up the webserver and access the root at http://localhost:55240/ the link generated for my subnode is http://www.pax.se/en.aspx
If I manually type in http://localhost:55240/en.aspx I get served the correct page for the correct locale. On this page the Razor navi will show the correct relative link /en.aspx for "itself". But If I navigate away to another page the link will revert back to http://www.pax.se/en.aspx

Not sure if it helps, but I also experienced that sometimes it worked and gave me relative URLs and sometime it gave me absolute URLs. After including the port in the domain settings, it worked for me. But when my colleague accessed, it gave him absolute URLs again.

Now I removed the port from the domain settings ONLY for the root node and it seems to work now. The subnodes with domain settings still have the port in it... 

This feels strange to me!
 

@Stephen Did you figure it out? I suspect I am having the same issues here.

Not yet, got busy... will try to look into it today.

Man, why did you do this change for the hostnames? I just upgraded a live website, damn me!

Domain redirects such as www.mydomain.com (main lang) --> as www.mydomain.co/en-gb/home.aspx works,

But when I go to www.ilmiodominio.com its redirected to www.mydomain.com/en-gb/home.aspx instead of www.ilmiodominio.com/it/ch/home.aspx... I had to add some rules in my UrlRewriting.config such as:

add name="itRewrite" redirect="Domain" ignoreCase="true" virtualUrl="http://www.ilmiodominio.com/$" destinationUrl="~/it-ch/home.aspx"

Also I noted for URL Aliases it's a mess now, www.ilmiodominio.com/aliastohelp (alias to /it-ch/help.aspx) ... page is displayed correctly but menus and translations are from the default language:

System.Threading.Thread.CurrentThread.CurrentUICulture.Name returns the correct culture when I browse the normal pages, but when I browse an url alias it returns the default one...

So now I have to code a solution because the culture is not given correctly...I have to change the helper I had in my App_Code to set the correct language...

WHAT A MESS MAN, the hostnames were just working fine before...

The hostnames were just working fine before...

Considering the number of issues and misunderstandings that were reported in the past...we had a slightly different opinion and decided to clean up the thing.

Our intention was to do it as transparently as possible, but obviously in your case, we've failed, and I can understand your frustration. Unfortunately, in some cases, minor changes will indeed be required. Can I help you figure out what's going wrong, what can be solved just by changing your configuration, and what may be bugs on our side? Do not start changing your code immediately, I'd rather fix Umbraco!

1) could you give me an idea of what your content tree looks like, and which hostnames are set on which node?

2) you mention domain redirects. Can you tell me how these redirects are implemented? What causes www.mydomain.com to be redirected to www.mydomain.com/en-gb/home.aspx? Same for www.ilmiodominio.com?

3) When you mention url aliases, I assume you are talking about the umbracoUrlAlias property? Again if you could give me an idea of the content tree and which node has an alias, that would help.

4) The culture beeing wrong when browsing through an url alias smells like a bug... but again I'd like to see the content tree.

Really hoping I can help,

Stephan

Hi Stephen,

I have a website with different domains, and different languages.

my umbraco "Content" looks like this:

Content
-Website (I need this container as I have other "folders which I need separate)
--en-gb (/en-gb.aspx) this document type has a property "redirector" where I can pickup a node, I picked up "/en-gb/home.aspx" so when I browse to /en-gb/ I arrive automatically at /en-gb/home.aspx
---home (/en-gb/home.aspx)
---habitat (/en-gb/habitat.aspx) umbracoUrlAlias: /habitat
--it-ch (/it-ch.aspx) this document type has a property "redirector" where I can pickup a node, I picked up "/it-ch/home.aspx" so when I browse to /it-ch/ I arrive automatically at /en-gb/home.aspx
---home (/it-ch/home.aspx)
---abitare (/it-ch/abitare.aspx) umbracoUrlAlias: /abitare
-SomeOTherFolder for other document types...

Domains

www.mydomain.com (for en-gb version) : has a webconfig with the following entry:
httpRedirect enabled="true" destination="http://www.mydomain.com$S$Q" exactDestination="true" httpResponseStatus="Permanent"

www.ilmiodominio.com (for it-ch version) : has a webconfig with the following entry:
httpRedirect enabled="true" destination="http://www.ilmiodominio.com$S$Q" exactDestination="true" httpResponseStatus="Permanent"

I didn't setup these redirects in the web.config, but before, they were working. When I was browsing to www.ilmiodominio.com I was redirected automatically to www.ilmiodominio.com/it-ch/home.aspx not the case after the upgrade, thus I had to add an entry in my UrlRewriting.config as explained above.

I use master pages containing a usercontrol for some special content. This user control inheritst from a BaseUSerControl I created. There I want to read the culture. Now the following problem occurs:

when I debug in visual studio and browse to /it-ch/abitare.aspx:
PageCulture = System.Threading.Thread.CurrentThread.CurrentUICulture.Name.ToLower();
PageCulture returns correctly : "it-ch".

When I visit one of the pages containing umbracoUrlAlias, for example /abitare (alias to /it-ch/abitare.aspx) the PageCulture returns en-gb.
I tried to search in the umbraco 4.10.1 source code all occurrences for System.Threading.Thread.CurrentThread.CurrentUICulture and there are about 10 files to be analyzed. I tried to add the projects to my project, in order to debug and eventually submit a fix, but things are not working as expected...

...so in my case I will end writing a dirty hack to check the Request.RawURL property. If the url doesn't contain one of my cultures at the beginning, I have to write a logic to get the culture, and then initialize again the System.Threading.Thread.CurrentThread.CurrentUICulture with the correct culture, not the default (wrong) one by umbraco. Quite a dirty solution so I'd like to find the bug in the umbraco source and patch it myself if possible.

To keep it simple, if you wanna help me and test a simple case, try in your multilanguage test project to add to your pages the umbracoUrlAlias property, add somewhere a string that reads from System.Threading.Thread.CurrentThread.CurrentUICulture.Name and see what happens.

Thx for letting me know, it's quite critical here. It's friday and the website is live and I need it to be working somehow before I go home.

I begin to understand. Few questions, though:

Do you have any hostnames setup? Via the content contextual menu Manage hostnames?

What is the "redirector" property? Do you have a package that handle it? Or is it actually umbracoRedirectId or something?

When you say a domain "has a webconfig" does it mean you're running two different IIS sites?

You can directly mail me at sgay _at_ pilotine.com so things move faster.

Hostnames yes I set them as you explained to the guy before. Before your change it was sufficient to configure e.g. the node en-gb to www.ilmiodominio.com now I did as you explained: hostname www.ilmiodominio.com/en-gb (this will also create an absolute link to www.ilmiodominio.com/en-gb.aspx and also to www.ilmiodominio.com/en-gb/.aspx which seems also buggy...)

The redirector is a umbracoRedirect standard property, so it's handled by umbraco directly.

As you said, the System.Threading.Thread.CurrentThread.CurrentUICulture not reading correctly smells also to me like a bug, I think the problem is in the umbraco.Web project

File BaseRest\BaseRestHandler.cs

Line 112: Method:

        private static bool TrySetCulture(string domain)
        {
            var uDomain = global::umbraco.cms.businesslogic.web.Domain.GetDomain(domain);
            if (uDomain == null) return false;
            System.Threading.Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo(uDomain.Language.CultureAlias);
            return true;
        }

But I'm not sure as I could not set all references in the various projects etc.

The file you're looking at for the culture is not the right file, that one is for the /base rest handler which you don't seem to be using. The culture is set in Umbraco.Web.Routing.PublishedContentRequest.ProcessRequest(). But before we address the culture we have to understand the domains & such. I'm not sure yet I understand which domain has been set on which node.

What I'd do is remove all the redirects and all the url aliases and setup content as follows:

Content
- WebSite
- - EN-GB - hostname: www.mydomain.com - lang EN-GB - umbracoRedirect to Home
- - - Home
- - - Habitat
- - IT-CH - hostname: www.ilmiodominio.com - lang IT-CH - umbracoRedirect to Home
- - - Home
- - - Abitare
- Other

And then www.mydomain.com/ will redirect to www.mydomain.com/home which will work... and www.mydomain.com/habitat will work too.

Or you could use umbracoInternalRedirectId to Home so that www.mydomain.com doesn't even redirect but displays the homepage.

Stephan

I see your point, the problem is, even if the urls were ugly, they are known by the customer, by other pages, by search engines including the "it-ch" in the url... so for example home should not be accessible under www.ilmiodominio.com/home.aspx but under www.ilmiodominio.com/it-ch/home.aspx

see what I mean? Maybe here you did a breaking change, if there is an option to preserve the "it-ch" or "en-gb" in  the urls, please let me know beacause I need to keep that.

About the varous web.config files I forgot to answer, they are saves on the server, IIS. They were created by the sysadmins of our company just to allow the website to be browsed both on www.ilmiodominio.com and also without "www" : ilmiodominio.com.

Got it.So you want:

www.mydomain.com is a valid url and redirects to www.mydomain.com/en-gb/home
www.mydomain.com/en-gb is a valid url and redirects to www.mydomain.com/en-gb/home
www.mydomain.com/en-gb/home is a valid url and displays the home
www.mydomain.com/en-gb/habitat is a valid url and displays the habitat page
www;mydomain.com/habitat is _also_ a valid url and displays the habitat page

And then the same for ilmiodominio.com. Right?

Would it be OK to accept urls such as /en-gb/home in requests, but generate urls such as /home from now on? So the urls with /en-gb still work and the search engines, etc are happy, but when Umbraco creates an url is uses the short /home form?

Then I'd do with:

Content
- WebSite
- - EN-GB - hostname www.mydomain.com - lang EN-GB - umbracoRedirect to Home
- - - Home
- - - Habitat
- - IT-CH - hostname www.ilmiodominio.com - lang IT-CH - umbracoRedirect to Home
- - - Home
- - - Abitare
- Other

And no aliases, and no httpRedirect, and two url-rewriting rules to rewrite (not redirect)

www.mydomain.com/en-gb/(.*)$ to www.mydomain/$1
www.ilmiodominio.com/it-ch/(.*)$ to www.ilmiodominio/$1

See what I mean?

Hi, yep the situation is that one, just a little precision: /en-gb/home.aspx (with ".aspx") and yes also for the italian version.

Mmmh to change the URLs it's a bit an issue, because I need the OK of the customer. I promised the customer a simple upgrade process so I have to keep things simple and no breaking changes. Redirects from en-gb/home.aspx to /home.aspx I'm not sure will be appreciated... I mean if I had to create a website from scratch, that would be perfect, but I need compatibility with my existing environment now... that's why if there is a "old way" option to keep it working like before, I would be really happy, even if it's a patch to my installation only.

Also the customer really needs aliases for advertizing etc. so I have let's say about 50 important aliases like the "habitat" one stated above, and the user can reach the same page via normal navigation or using the alias.

By the way I managed to attach umbraco.Web to my project, so I can edit the original umbraco source code and debugging Umbraco.Web.Routing.PublishedContentRequest.ProcessRequest().

At line 61 I placed a breakpoint and added "this" to the watch.

when I browse a page: this.Domain contains the domain, this.hasDomain is true.

when I browse an alias: this.Domain = null, this.hasDomain is false. So there is a bug, on my opinion, detecting the urlAliases...

If you tell me where I can modify some code I can do that, deploy the patched umbraco.dll and I'll be more than happy.

Thanks Stehpen for your great support, I appreciate.

I debugged and tried many things and I ended to write my own culture helper as follows:

                string url = Request.Url.AbsoluteUri;

                Node currentNode = Node.GetCurrent();
                string currentNodeUrl = currentNode.NiceUrl;

                string _lang = currentNodeUrl.Substring(1, 2);//url begins like this: /fr-ch/
                string _country = currentNodeUrl.Substring(4, 2).ToUpper();
                string _culture = _lang + "-" + _country;

                //set the culture again, as umbraco failed to get it correctly.
                Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(_culture);
                Thread.CurrentThread.CurrentUICulture = new CultureInfo(_culture);

Cheers

I'm really sorry you had to go through all this ;-(

To anybody reading this: the correct solution is described below. It _should_ have been working out-of-the-box in 4.11 but due to a stupid mistake it does not, see issue http://issues.umbraco.org/issue/U4-1245 about it -- should have a fix in a couple of days.

So, the solution:

Content
- WebSite (domain: www.mydomain.com lang: en-gb) (domain: www.ilmiodominio.com lang: it-ch)
- - EN-GB (domain: * lang: en-gb) + redirect to Home
- - - Home
- - - Habitat (alias: habitat)
- - IT-CH (domain: * lang: it-ch) + redirect to Home
- - - Home
- - - Abitare (alias: abitare)

Thanks to the new wildcard domains introduced in 4.11.

Stephan

is working on a reply...