I know there are some bugs related to this setting but if there weren't any, why would you not turn on useDomainPrefixes. Even if you don't have a multisite solution it doesn't really matter if domain prefixes are used, right?
Maybe I'm missing something and I'd be happy to see some usecases.
Actually most of our website have useDomainPrefixes set to false. Some of them haven't. That depends entirely on the situation, and we're happy to have the choice, although it's rather buggy. All our websites use the same node structure as in the Tea Commerce starter kit. Our use cases are a little hard to explain, but I will give it a try.
This is what our content tree looks like:
A short explanation of the different parts. All in all our structure is securing that ALL our websites can have multiple languages AND multiple subwebsites, if the customer should ever want it. The "Tea Commerce" node is the website node and will contain general information central for that site. The "en" and "da" nodes are the different languages for that particular website. The language nodes does usually not have a template, but can be given one if necessary. Any domains for the website is chosen on the language nodes with the "Manage hostnames" option. Beneath the language nodes the sites' actual content is placed.
When the useDomainPrefixes value is set to false the url of the website will be: starterkit.teacommerce.net/en/frontpage/
When the useDomainPrefixes value is set to true the url of the website will be: starterkit.teacommerce.net/frontpage/
So now the question is, why choose the one or the other. Now please hang on, because this is going to get very hairy and technical (What we all love ofcause). I will try and set it up in the different subjects to take in mind when choosing. Bare in mind that some of my arguments will contradict each other, making the choice even harder :-)
Dictionary items: For dictionary items to work in Umbraco there must be a domain for each language. If you have a domain for each langauge you have a case like our customer Global Wind Power. Their website have useDomainPrefixes set to true and have a domain for each language. Dictionary items work like a charm on that site.
If the website does not have a domain for each language for one or the other reason you will have a problem. We have had a customers website who where in that situation. They did not want multiple domains as their main domain where a large part of their identity. In their case we would manually set the culture of the website and the dictionary items would then work as expected.
SEO: Another issue is SEO and our discutions is based on two main choices. To have multiple domains or not. In the above case with Global Wind Power their langauges will be treated as seperate websites and will rank accordingly. Each language will not help each others page rank, but will, on the other hand, not give penalties to each others page rank. Furthermore each individual language will in theory recieve a better rank higher local rank. Local meaning in the country they are meant for.
On the other hand, using only one domain and useDomainPrefixes false will have the opposite effect. A middle ground could be to use sub domains as we have done at Christine Headwear where useDomainPrefixes is also set to true. In theory this solutions should make the overall website ranking increase.
NOTE: I have no actual proof of the theories above, but they are derived from googles own directions.
Problems: When useDomainPrefixes is set to false, there is nothing that stops the user from accessing any page on the website with any of the domains that points to the website. That will mean possible duplicate content, which is a SEO nightmare. To secure that we do not get in that situation use ISAPI rewrite and throw visitors back to the correct domain.
Changing between useDomainPrefixes false/true will mean the los of any pageranking for all the pages affected by the url change. We have our own small "package" that will track these changes and redirect the user to the new url. We do believe though, that Umbraco should handle this. It's such a central problem and has everything to do about content. 301 redirect whenever a page is moved somehow.
Conclusion: useDomainPrefixes = true might be the best solution in most cases. But there's certainly some corner cases in which it's not an option. Or am I totally wrong here?
By that i might have fuelled a fierce battle. I'm ready to take the discution though as we're always ready to learn new and better ways of doing things!
uComponents, Dev/Staging One important thing to remember is, that some packages (uComponents URL-Picker, et al) use NiceUrl (internally) to resolve the link from the selected document's @id. This link is then saved inside the xml-structure as link (to have a consistent field to query for all content types, being it external HTTP-links or internal node ids). When you add content using a development and/or staging scenario, this results in a nightmare, because you will end up with your production server getting pushed "http://dev.example.com/foo/" via i.e. Courier. Whoops! ;)
It might be tempting to argue that you should resolve the @id with NiceUrl every time you render (xsl/razor), but code can be kept shorter and cleaner when there is a single property/field like "link" for all content types (doc, link, media, upload) of i.e. URL-Picker.
SEO, duplicate content The duplicate content problem is not really a problem, with 301 Tracker package and the use of (resolving to the correct URI) all is good. Also, the IIS Rewriting is really good and you can redirect obviously incorrect (undesired) URIs very easy and flexible (like Rune does with ISAPI) at first stage. The canonical link takes care of the rest.
But not everyone has the opportunity (or the skills) to use ISAPI rewrite, so it's a layer of complexity that shouldn't be necessary I belive. A cms should handle stuff like that in my oppinion.
When the useDomainPrefixes value is set to false the url of the website will be: starterkit.teacommerce.net/en/frontpage/
When the useDomainPrefixes value is set to true the url of the website will be: starterkit.teacommerce.net/frontpage/
That depends on whethere you set umbracoHideTopLevelNodeFromPath to true.
They did not want multiple domains as their main domain where a large part of their identity. In their case we would manually set the culture of the website and the dictionary items would then work as expected.
You can set up the domains in umbraco to be: mydomain.com/en and mydomain.com/dk so you'll always have a language attached to them, while it is still the same domain.
SEO issues: IMHO has nothing to do with domain prefixes, it's just how you choose to set up the domains / pages.
When useDomainPrefixes is set to false, there is nothing that stops the user from accessing any page on the website with any of the domains that points to the website.
Hence my question, why should it ever be set to false. (tip: you can also add a canonical URL to the headers).
Changing between useDomainPrefixes false/true will mean the los of any pageranking for all the pages affected by the url change.
In no way am I advocating people change it, for this very reason. But moving forward, I think we should not have the option in the config file. New installs will always have it set to true, old installs can keep using the config option to force it to false if it's really necessary. But by it being hidden, it will not tempt people so much to turn it off.
@Marc I would say the implementation of those datatypes is then wrong, they should store id's.
It will solve a lot of duplicate content issues so set it to true will be nice. You are right Sebastiaan, that url's should never be stored but since that's the case now at least warn the developers that do suchs things that their packages will break.
And to test if this will give a lot of issues wouldn't it be nice to set the config option to true for the next 4.x releases and remove the config option in 6.x?
Why did no one ever tell us that before?? :D We have had multiple discutions here on our with this very subject, with NO result, and now you just hits the nail spot on. We will test the umbracoHideTopLevelNodeFromPath and mydomain.com/en right away.
If they both work I withdraw all my talk about useDomainPrefixes false, as it will not be necessary any more.
Now I have tested your input in my scenario from above. Conclusion is that umbracoHideTopLevelNodeFromPath have no effect in my scenario. I guess that is because of the domains being set on the language nodes and not the root node.
Also I can't get the mydomain.com/en on the umbraco node to work. It simply cannot find the site then.
So we're back to square one. The useDomainPrefixes stile HAVE to be there and we will need to be able to set it to false!
So I think I just came accross something related. I have a multi-site-multi language setup (forced to be like this because of the way dictionary items work). So from root, I have "site" nodes, then "language" nodes then finally the content. All of which are landable pages. I've manage hostnames sending www.xyz.com and xyz.com to the site node, then fr.xyz.com and en.xyz.com to the language nodes. So when I useDomainPrefixes=true, I get these:
My situation right now though is that I want my site to respond to "http://fr.xyz.local/blogue/" but I want links on that page to be "/blogue/". Right now, whenever I print NiceUrl and such, I get the full URL with domain... When I set to false, my links look like "<a href="/fr/blogue/">Blogue</a>" which is better, but still not the behavior I'm looking for.
I'll probably either override .NiceUrl ou create a seperate extension method to "DynamicNode.GetMyOwnNiceUrl()".
Relative : always give relative urls (though some may not work)
Auto : give urls that work, relative if possible, else absolute (what 4.11 does at the moment)
And we ditch useDomainPrefixes that is misleading.
In addition document that hideTopLevelNodeFromPath only works when you have no domain set, but as soon as you set a domain, everything above that domain is hidden from path automatically whatever the value of hideTopLevelNodeFromPath (what 4.11 does at the moment).
useDomainPrefixes when should it be set to false?
I know there are some bugs related to this setting but if there weren't any, why would you not turn on useDomainPrefixes. Even if you don't have a multisite solution it doesn't really matter if domain prefixes are used, right?
Maybe I'm missing something and I'd be happy to see some usecases.
Thanks!
Hi Sebastiaan,
Actually most of our website have useDomainPrefixes set to false. Some of them haven't. That depends entirely on the situation, and we're happy to have the choice, although it's rather buggy. All our websites use the same node structure as in the Tea Commerce starter kit. Our use cases are a little hard to explain, but I will give it a try.
This is what our content tree looks like:
A short explanation of the different parts. All in all our structure is securing that ALL our websites can have multiple languages AND multiple subwebsites, if the customer should ever want it.
The "Tea Commerce" node is the website node and will contain general information central for that site.
The "en" and "da" nodes are the different languages for that particular website. The language nodes does usually not have a template, but can be given one if necessary. Any domains for the website is chosen on the language nodes with the "Manage hostnames" option.
Beneath the language nodes the sites' actual content is placed.
When the useDomainPrefixes value is set to false the url of the website will be:
starterkit.teacommerce.net/en/frontpage/
When the useDomainPrefixes value is set to true the url of the website will be:
starterkit.teacommerce.net/frontpage/
So now the question is, why choose the one or the other. Now please hang on, because this is going to get very hairy and technical (What we all love ofcause). I will try and set it up in the different subjects to take in mind when choosing. Bare in mind that some of my arguments will contradict each other, making the choice even harder :-)
Dictionary items:
For dictionary items to work in Umbraco there must be a domain for each language. If you have a domain for each langauge you have a case like our customer Global Wind Power. Their website have useDomainPrefixes set to true and have a domain for each language. Dictionary items work like a charm on that site.
If the website does not have a domain for each language for one or the other reason you will have a problem. We have had a customers website who where in that situation. They did not want multiple domains as their main domain where a large part of their identity. In their case we would manually set the culture of the website and the dictionary items would then work as expected.
SEO:
Another issue is SEO and our discutions is based on two main choices. To have multiple domains or not. In the above case with Global Wind Power their langauges will be treated as seperate websites and will rank accordingly. Each language will not help each others page rank, but will, on the other hand, not give penalties to each others page rank. Furthermore each individual language will in theory recieve a better rank higher local rank. Local meaning in the country they are meant for.
On the other hand, using only one domain and useDomainPrefixes false will have the opposite effect. A middle ground could be to use sub domains as we have done at Christine Headwear where useDomainPrefixes is also set to true. In theory this solutions should make the overall website ranking increase.
NOTE: I have no actual proof of the theories above, but they are derived from googles own directions.
Problems:
When useDomainPrefixes is set to false, there is nothing that stops the user from accessing any page on the website with any of the domains that points to the website. That will mean possible duplicate content, which is a SEO nightmare. To secure that we do not get in that situation use ISAPI rewrite and throw visitors back to the correct domain.
Changing between useDomainPrefixes false/true will mean the los of any pageranking for all the pages affected by the url change. We have our own small "package" that will track these changes and redirect the user to the new url. We do believe though, that Umbraco should handle this. It's such a central problem and has everything to do about content. 301 redirect whenever a page is moved somehow.
Conclusion:
useDomainPrefixes = true might be the best solution in most cases. But there's certainly some corner cases in which it's not an option. Or am I totally wrong here?
By that i might have fuelled a fierce battle. I'm ready to take the discution though as we're always ready to learn new and better ways of doing things!
/Rune
uComponents, Dev/Staging
One important thing to remember is, that some packages (uComponents URL-Picker, et al) use NiceUrl (internally) to resolve the link from the selected document's @id. This link is then saved inside the xml-structure as link (to have a consistent field to query for all content types, being it external HTTP-links or internal node ids). When you add content using a development and/or staging scenario, this results in a nightmare, because you will end up with your production server getting pushed "http://dev.example.com/foo/" via i.e. Courier. Whoops! ;)
It might be tempting to argue that you should resolve the @id with NiceUrl every time you render (xsl/razor), but code can be kept shorter and cleaner when there is a single property/field like "link" for all content types (doc, link, media, upload) of i.e. URL-Picker.
SEO, duplicate content
The duplicate content problem is not really a problem, with 301 Tracker package and the use of (resolving to the correct URI) all is good. Also, the IIS Rewriting is really good and you can redirect obviously incorrect (undesired) URIs very easy and flexible (like Rune does with ISAPI) at first stage. The canonical link takes care of the rest.
Marc
Agreed Marc.
But not everyone has the opportunity (or the skills) to use ISAPI rewrite, so it's a layer of complexity that shouldn't be necessary I belive. A cms should handle stuff like that in my oppinion.
/Rune
@Rune
That depends on whethere you set umbracoHideTopLevelNodeFromPath to true.
You can set up the domains in umbraco to be: mydomain.com/en and mydomain.com/dk so you'll always have a language attached to them, while it is still the same domain.
SEO issues: IMHO has nothing to do with domain prefixes, it's just how you choose to set up the domains / pages.
Hence my question, why should it ever be set to false. (tip: you can also add a canonical URL to the headers).
In no way am I advocating people change it, for this very reason. But moving forward, I think we should not have the option in the config file. New installs will always have it set to true, old installs can keep using the config option to force it to false if it's really necessary. But by it being hidden, it will not tempt people so much to turn it off.
@Marc
I would say the implementation of those datatypes is then wrong, they should store id's.
Make sure to also read Stéphane's breakdown of the routing refactor, he's gone deep into the request handling and made the code for it more readable, more logical and best of all: testable - https://groups.google.com/forum/?fromgroups=#!topic/umbraco-dev/sukKQw8BZxg
It will solve a lot of duplicate content issues so set it to true will be nice. You are right Sebastiaan, that url's should never be stored but since that's the case now at least warn the developers that do suchs things that their packages will break.
And to test if this will give a lot of issues wouldn't it be nice to set the config option to true for the next 4.x releases and remove the config option in 6.x?
Cheers,
Richartd
EDIT: did not work - see next reply
@Sebastiaan
Why did no one ever tell us that before?? :D
We have had multiple discutions here on our with this very subject, with NO result, and now you just hits the nail spot on. We will test the umbracoHideTopLevelNodeFromPath and mydomain.com/en right away.
If they both work I withdraw all my talk about useDomainPrefixes false, as it will not be necessary any more.
Thanks
/Rune
@Sebastiaan
Now I have tested your input in my scenario from above. Conclusion is that umbracoHideTopLevelNodeFromPath have no effect in my scenario. I guess that is because of the domains being set on the language nodes and not the root node.
Also I can't get the mydomain.com/en on the umbraco node to work. It simply cannot find the site then.
So we're back to square one. The useDomainPrefixes stile HAVE to be there and we will need to be able to set it to false!
/Rune
So I think I just came accross something related. I have a multi-site-multi language setup (forced to be like this because of the way dictionary items work). So from root, I have "site" nodes, then "language" nodes then finally the content. All of which are landable pages. I've manage hostnames sending www.xyz.com and xyz.com to the site node, then fr.xyz.com and en.xyz.com to the language nodes. So when I useDomainPrefixes=true, I get these:
http://fr.xyz.local/blogue/
And if I useDomainPrefixes=false, I get these:
http://fr.xyz.local/fr/blogue/
My situation right now though is that I want my site to respond to "http://fr.xyz.local/blogue/" but I want links on that page to be "/blogue/". Right now, whenever I print NiceUrl and such, I get the full URL with domain... When I set to false, my links look like "<a href="/fr/blogue/">Blogue</a>" which is better, but still not the behavior I'm looking for.
I'll probably either override .NiceUrl ou create a seperate extension method to "DynamicNode.GetMyOwnNiceUrl()".
So that's my use case, enjoy!
Seb
Hi Sébastien,
Yes, your scenario is exactly the same as ours. It would be nice if NiceUrl could be told to either give you with or without the domain.
/Rune
Proposing option urlProviderMode which would be
And we ditch useDomainPrefixes that is misleading.
In addition document that hideTopLevelNodeFromPath only works when you have no domain set, but as soon as you set a domain, everything above that domain is hidden from path automatically whatever the value of hideTopLevelNodeFromPath (what 4.11 does at the moment).
Thoughts?
Back to this thread. Url provider mode has now been implemented, amongst other features that should solve most issues.
See my presentation at CodeGarden 13 at http://www.zpqrtbnk.net/TheUmbraco6RequestPipeline.pdf
Stephan
is working on a reply...