I've got a bit of a bizarre one here on 7.8.1 and I'm not sure it it's "by design".
I have a multilingual site running multiple locales.
Each locale has it's own path specified with umbracoUrlname:
/us/ - for the US English (culture en-US)
/gb/ - for the UK English (culture en-GB)
/cn/ - for the Chinese (culture zh-CN)
In "Culture and Hostnames"; I have only the culture set and NO DOMAIN specified. In the web.config I have
umbracoHideTopLevelNodeFromPath = false
So, the US site is on the url mysite.com/us/ whilst the GB site is on the url mysite.com/gb/ etc...
This is all absolutely fine and works as expected, with the exception of the following off behaviour.
If I access front-end of the site without a path; the first content-node in the tree has it's LINK reset to "/" instead of "/us/".
If I access the "/us/" path then the LINK on the "/us/" site is updated back to "/us/" and I can easily re-created this behaviour. If I change the sort order of my content nodes then it is always the first content-node that has it's LINK reset to "/".
Is this "by design" because I'm worried that there is bug here and that the node LINK should never be updated based upon front-end requests?
Of course, this is causing me an issue because the front-end requests are causing the links to change for any content nested within the affected content-node :(
Thanks guys,
Splinx
PS: I can send some screen-grabs if it helps to explain the issue more clearly.
Yes, I think it is by design, (or at least has always been the case)
I think, if there is a Culture and Hostname domain set on the different site pages - then the url you seen in the backoffice for the homepage of the first site won't default to / ...
... but a visit to the / will still take you to the first item in the Umbraco content tree, if it doesn't match anywhere else.
What I tend to do on multilingual sites though, is create a single top level 'choose your country' page as the first item in the list (see screenshot) - this then responds to the default / request... and I list the multilingual / territory sites, in the rest of Umbraco on this page, for users to switch to their preferred option.
When I say it's probably 'by design'.... what I mean is that in a single site setup in Umbraco you wouldn't want the first node in the tree eg Home, to have the url /home - so 'by design' this first element becomes '/' the root of the site...
... and in a Multi-site setup, I think 'the design' is anticipating each top level site will have a Custom Domain set and so the issue shouldn't manifest as the request for the particular domain, will route to that part of the tree...
... so it appears the issue occurs when you have a Multi-site setup, without different domains set... and the thinking probably here is, how do you decide which site should respond to '/' ... ? and they have chosen the first item in the tree... which is why in those circumstances I create a page there as a language/territory switcher...
I say 'by design', as it could just have easily just evolved accidentally this way over many years of iterations.
Lots of sites will be built expecting this behaviour, so to change it now for V7 could be a big breaking change for people, in V8 how languages, and variants are implemented is being completely revisited, the method of Urls mapping to content when multi-language variations exist is being rethought and will be implemented slightly differently, so hopefully in V8 there will be less of an unexpected quirk here.
But for now let's update the docs, so future people don't get caught out in the same way.
Everything you say here is very well considered and makes complete sense to me - thank you sir.
I've read both of the specific articles you have linked above and I think that I might have spotted it in the multi language setup piece; perhaps listed as a gotcha or warning?
I guess the only bit that I was querying really was the different behaviour exhibited when a domain was set or not. Because the data was being affected in the CMS without any explanation, I thought it was a bug or an error being caused by my custom code.
I'm a great believer in systems self-documenting for users so they see what is occurring and why. For this reason I would heartily recommend the audit trail on the affected document being updated when the LINK is being set. Something along the lines of "Updated LINK from {x} to {y} because no root document exists in the solution - click {here} for more information.
I am MEGA IMPRESSED with the feedback in this community as always!
Link to first content node is resetting to "/" on front-end request?
Hi Guys,
I've got a bit of a bizarre one here on 7.8.1 and I'm not sure it it's "by design".
I have a multilingual site running multiple locales.
Each locale has it's own path specified with umbracoUrlname:
In "Culture and Hostnames"; I have only the culture set and NO DOMAIN specified. In the web.config I have
So, the US site is on the url mysite.com/us/ whilst the GB site is on the url mysite.com/gb/ etc...
This is all absolutely fine and works as expected, with the exception of the following off behaviour.
If I access front-end of the site without a path; the first content-node in the tree has it's LINK reset to "/" instead of "/us/".
If I access the "/us/" path then the LINK on the "/us/" site is updated back to "/us/" and I can easily re-created this behaviour. If I change the sort order of my content nodes then it is always the first content-node that has it's LINK reset to "/".
Is this "by design" because I'm worried that there is bug here and that the node LINK should never be updated based upon front-end requests?
Of course, this is causing me an issue because the front-end requests are causing the links to change for any content nested within the affected content-node :(
Thanks guys,
Splinx
PS: I can send some screen-grabs if it helps to explain the issue more clearly.
Hi Splinx
Yes, I think it is by design, (or at least has always been the case)
I think, if there is a Culture and Hostname domain set on the different site pages - then the url you seen in the backoffice for the homepage of the first site won't default to / ...
... but a visit to the / will still take you to the first item in the Umbraco content tree, if it doesn't match anywhere else.
What I tend to do on multilingual sites though, is create a single top level 'choose your country' page as the first item in the list (see screenshot) - this then responds to the default / request... and I list the multilingual / territory sites, in the rest of Umbraco on this page, for users to switch to their preferred option.
regards
Marc
Thanks Marc,
At least I know where I am now and am not going crazy. :-)
It's a real shame that this behaviour not documented anywhere because, personally, I think it's odd that the LINK in the admin updates.
Especially since this built-in behaviour changes depending on whether, as you say, the domain is set or not.
Is there any chance that someone from Umbraco can explain this reasoning or if there's a better way to manage this?
Thanks again,
Splinx
Hi Splinx
Well we can sort the documentation part here:
https://github.com/umbraco/UmbracoDocs/issues
if we create an issue, one helpful thing with your 'fresh eyes' is where in the documentation https://our.umbraco.com/documentation/ would you look for such info? the Mulitlanguage Setup page - https://our.umbraco.com/documentation/Tutorials/Multilanguage-Setup/ ? or routing - https://our.umbraco.com/documentation/Reference/Routing/?
When I say it's probably 'by design'.... what I mean is that in a single site setup in Umbraco you wouldn't want the first node in the tree eg Home, to have the url /home - so 'by design' this first element becomes '/' the root of the site...
... and in a Multi-site setup, I think 'the design' is anticipating each top level site will have a Custom Domain set and so the issue shouldn't manifest as the request for the particular domain, will route to that part of the tree...
... so it appears the issue occurs when you have a Multi-site setup, without different domains set... and the thinking probably here is, how do you decide which site should respond to '/' ... ? and they have chosen the first item in the tree... which is why in those circumstances I create a page there as a language/territory switcher...
I say 'by design', as it could just have easily just evolved accidentally this way over many years of iterations.
Lots of sites will be built expecting this behaviour, so to change it now for V7 could be a big breaking change for people, in V8 how languages, and variants are implemented is being completely revisited, the method of Urls mapping to content when multi-language variations exist is being rethought and will be implemented slightly differently, so hopefully in V8 there will be less of an unexpected quirk here.
But for now let's update the docs, so future people don't get caught out in the same way.
regards
Marc
Hi Marc,
Everything you say here is very well considered and makes complete sense to me - thank you sir.
I've read both of the specific articles you have linked above and I think that I might have spotted it in the multi language setup piece; perhaps listed as a gotcha or warning?
I guess the only bit that I was querying really was the different behaviour exhibited when a domain was set or not. Because the data was being affected in the CMS without any explanation, I thought it was a bug or an error being caused by my custom code.
I'm a great believer in systems self-documenting for users so they see what is occurring and why. For this reason I would heartily recommend the audit trail on the affected document being updated when the LINK is being set. Something along the lines of "Updated LINK from {x} to {y} because no root document exists in the solution - click {here} for more information.
I am MEGA IMPRESSED with the feedback in this community as always!
Sincere regards,
Splinx
Thanks Splinx
I've raised an issue with the docs here...
https://github.com/umbraco/UmbracoDocs/issues/1143
and marked it 'up for grabs'
with regard to the 'self-documenting' hint within Umbraco, suggest that's raised as a feature request here; https://github.com/umbraco/Umbraco-CMS/issues
regards
Marc
is working on a reply...