If useDomainPrefixes is false then what NiceUrl returns depend on the current request. If the hostname of the current request matches a defined hostname then NiceUrl should return a relative url, otherwise an absolute url. So...
Content - TopLevelNode (foo.example.com, bar.example.com) -- Page A
NiceUrl for Page A while browsing foo.example.com should be /page-a BUT if you setup your backend on umbraco.example.com then it will be http://foo.example.com/page-a -- so it's picking a domain when you're not currently browsing a defined domain. Do you see what I mean?
In our setup, we have added hostnames for each environment. Here is part of the current tree with hostnames
Content - Global - hostnames: staging.mydomain.com, dev.mydomain.com, mydomain.com.local - Regions list (page that lists all the regions) - GB - hostnames: gb.staging.mydomain.com, gb.dev.mydomain.com gb.mydomain.com.local - CH - no host names - FR - hostenames: ch.staging.mydomain.com/fr, ch.dev.mydomain.com/fr, ch.mydomain.com.local/fr - DE - hostenames: ch.staging.mydomain.com/de, ch.dev.mydomain.com/de, ch.mydomain.com.local/de
By what you're saying, a link to a node which is outside of the current tree will result in a full absolute Uri. That's fine. However, the problem now is that this absolute Uri that is pulled out is arbitrarily the last hostname that was entered for the region in question.
This was not the case in previous versions as only a relative path was returned. The problem is that the code that sets Url and NiceUrl arbitrarily picks the last hostname that was entered.
---
The other issue (from my 2nd post).. under the properties tab:
Link to document:http://gb.staging.mydomain.com/example-text-page/
If you create a link to a page on the GB website from the FR website, so you're browsing say ch.mydomain.com.local/fr which is not a valid hostname for the GB website, then NiceUrl will return an absolute url to the GB website, including the GB domain -- right. This is how it is supposed to work. Now I understand your issue, which is that we have to pick a domain, and if there's more than one domain... which one should we pick.
About the second issue: in the properties tab, it all depends on the url you're using to access the backend. I assume it is staging.mydomain.com/umbraco => not a valid domain on the FR branch, so NiceUrl appears as absolute. BUT once you'll be browsing the FR site, it will be relative again. See, it's dynamic -- each time you call NiceUrl we figure out which site you're currently browsing and re-create the url appropriately.
Which leaves us with the issue of... which domain should we pick. To be honest I had not foreseen this. 'Cos when you browse ch.dev.mydomain.com you want to pick dev.mydomain.com, and when you browse ch.staging.mydomain.com you want to pick staging.mydomain.com, right? Oh my. Let me think about it...
I get the rational for wanting to supply an absolute uri. The problem is that it wont work when multiple hostnames are defined. There is no way to define or detect which hostname to pull out.
This is the case even if we are not talking about environments, but just different domains in general. Taking the last domain entered wont work, and there's no way to figure out which one is the one to return.
The old functionality worked just fine. Everything was relative. If you wanted to get a domain for another tree then you could get it from the web.config or somewhere else.
I get your point which is totally valid. But it would cause other issues, wouldn't it?
Because then from ch.domain.com you'd go to ch.domain.com/an-english-page where the url should actually be www.domain.com/an-english-page.
I'm trying really hard to imagine something that works... mostly because I came to realize that one of our customer's website has the exact same issue that you faced, so I _have_ to find a solution.
You're talking about the ability to view a node which is not in the current tree, but using the current tree's base url.
It's a bit of a strange quirk but can be worked around very easily using url redirects, or redirects inside templates, or a module.
The algorithm is simple: get the node id of the node which owns the base url (hostname). If that id is not in the path of the page you're trying to view, then throw a 404.
I think, restoring the functionality back to the way it was, with relative paths all the time is the least pain, and doesnt break compatibility for multi-hostname, multi-region sites which are being upgraded.
v4.11.1 Link to document is last Alternative Link
I have multi region site.
Each top level node has Hostnames set for local, dev, staging.
Everything was working fine when the site was running 4.7.2. I ported (not upgraded) the code to a brand new 4.11.1 install and re-did the hotnames.
Before the port I would see /fr/some-page/ in Url and NiceUrl
Note I see http://staging.mydomain.com/fr/some-page/ in Url and NiceUrl.
I suppose that it's picking up the staging hostname because that was the last one that I entered. But this should not be happening right?
What is going on?
The request pipeline has been completely rewritten in 4.11 by Stephan.
Do you have the setting turned on or off?
I remember that when this is turned on, NiceUrl will always return the full URL.
If that's not it, wait for Stephan to comment on this.
If useDomainPrefixes is false then what NiceUrl returns depend on the current request. If the hostname of the current request matches a defined hostname then NiceUrl should return a relative url, otherwise an absolute url. So...
Content
- TopLevelNode (foo.example.com, bar.example.com)
-- Page A
NiceUrl for Page A while browsing foo.example.com should be /page-a BUT if you setup your backend on umbraco.example.com then it will be http://foo.example.com/page-a -- so it's picking a domain when you're not currently browsing a defined domain. Do you see what I mean?
Stephan
Hi Stephen
In our setup, we have added hostnames for each environment. Here is part of the current tree with hostnames
Content
- Global - hostnames: staging.mydomain.com, dev.mydomain.com, mydomain.com.local
- Regions list (page that lists all the regions)
- GB - hostnames: gb.staging.mydomain.com, gb.dev.mydomain.com gb.mydomain.com.local
- CH - no host names
- FR - hostenames: ch.staging.mydomain.com/fr, ch.dev.mydomain.com/fr, ch.mydomain.com.local/fr
- DE - hostenames: ch.staging.mydomain.com/de, ch.dev.mydomain.com/de, ch.mydomain.com.local/de
By what you're saying, a link to a node which is outside of the current tree will result in a full absolute Uri. That's fine. However, the problem now is that this absolute Uri that is pulled out is arbitrarily the last hostname that was entered for the region in question.
So if I'm on http://gb.mydomain.com.local but I have a link to a global regions list page which is http://staging.mydomain.com/regions-list/ - it should be http://mydomain.com.local/regions-list/ ;
This was not the case in previous versions as only a relative path was returned. The problem is that the code that sets Url and NiceUrl arbitrarily picks the last hostname that was entered.
---
The other issue (from my 2nd post).. under the properties tab:
Link to document:http://gb.staging.mydomain.com/example-text-page/
Alternative Links: http://gb.dev.mydomain.com/example-text-page/
http://gb.mydomain.com.local/example-text-page/
Link to document should be a relative path ie: /example-text-page/
But again, it is arbitrarily pulling out the LAST hostname that was entered (which was the staging hostname).
If you create a link to a page on the GB website from the FR website, so you're browsing say ch.mydomain.com.local/fr which is not a valid hostname for the GB website, then NiceUrl will return an absolute url to the GB website, including the GB domain -- right. This is how it is supposed to work. Now I understand your issue, which is that we have to pick a domain, and if there's more than one domain... which one should we pick.
About the second issue: in the properties tab, it all depends on the url you're using to access the backend. I assume it is staging.mydomain.com/umbraco => not a valid domain on the FR branch, so NiceUrl appears as absolute. BUT once you'll be browsing the FR site, it will be relative again. See, it's dynamic -- each time you call NiceUrl we figure out which site you're currently browsing and re-create the url appropriately.
Which leaves us with the issue of... which domain should we pick. To be honest I had not foreseen this. 'Cos when you browse ch.dev.mydomain.com you want to pick dev.mydomain.com, and when you browse ch.staging.mydomain.com you want to pick staging.mydomain.com, right? Oh my. Let me think about it...
I get the rational for wanting to supply an absolute uri. The problem is that it wont work when multiple hostnames are defined. There is no way to define or detect which hostname to pull out.
This is the case even if we are not talking about environments, but just different domains in general. Taking the last domain entered wont work, and there's no way to figure out which one is the one to return.
The old functionality worked just fine. Everything was relative. If you wanted to get a domain for another tree then you could get it from the web.config or somewhere else.
I get your point which is totally valid. But it would cause other issues, wouldn't it?
Because then from ch.domain.com you'd go to ch.domain.com/an-english-page where the url should actually be www.domain.com/an-english-page.
I'm trying really hard to imagine something that works... mostly because I came to realize that one of our customer's website has the exact same issue that you faced, so I _have_ to find a solution.
You're talking about the ability to view a node which is not in the current tree, but using the current tree's base url.
It's a bit of a strange quirk but can be worked around very easily using url redirects, or redirects inside templates, or a module.
The algorithm is simple: get the node id of the node which owns the base url (hostname). If that id is not in the path of the page you're trying to view, then throw a 404.
I think, restoring the functionality back to the way it was, with relative paths all the time is the least pain, and doesnt break compatibility for multi-hostname, multi-region sites which are being upgraded.
Back to this thread. I think we have solved it all now with 6.1.
See my presentation at CodeGarden 13 at http://www.zpqrtbnk.net/TheUmbraco6RequestPipeline.pdf
Stephan
is working on a reply...