Possible 4.11.1 back office bug - Manage Hostnames dialog
Hi,
I recently upgraded a production and staging instance to 4.11.1 from 4.7.1
.Net 4, Win 8, IIS 7, SQL 2008, No stacktrace.
When using the 'Manage Hostname' dialog to set domain path and language, no matter what I enter in the UI gives an 'Invalid Hostname' error. The domains I'm entering are correct (not invalid) and no record appears in the umbracoDomains table.
I've resorted to manually entering records in the umbracoDomains table but this isn't really a solution for us because non-developers need to be able to manage this themselves.
Have I found a UI bug? The 'Invalid Hostname' message appears instantly and there appears to be no server round trip on the validation.
What is the format of the domains you're trying to enter in the hostnames? And could you perhaps upgrade to 4.11.3 to see if that fixes the issue? I know that there unfortunately where some minor bugs in the mentioned version - however I can't remember if some of them were related to the manage hostnames dialogue.
Any reason you're not running the latest 4.11 (4.11.3.1)? I recall some bugs with the Manage Hostname dialog around 4.11. I see a few in the issue tracker that were fixed in 4.11.1, so theoretically you should be fine, but not sure if another fix got slipped in afterwards. Are you able to reproduce this on a fresh install? Maybe something was missed with the upgrade?
I have upgraded my local instance to 4.11.3 but unfortunately that hasn't changed the issue. Domains are in the format http://mydomainname.com/path/to/the/language/homage. We have 10 active languages in the language selector.
It's odd - even opening up a hostname that currently is ok and resaving that produces the Invalid Hostname issue. I can't recreate this on a fresh installation.
Any other things I should try? Any help gratefully received!
As of 4.11 valid hostnames only support _one_ level ie www.site.com/foo but _not_ www.site.com/foo/bar so it's "normal" (at least expected) that what you are trying to do does not work. And in fact, I have plans to also remove support for the first level, ie only authorize www.site.com, as the first level is usually used for languages (/fr, /en...) and we have new ways (wildcard hostnames) to support that.
That being said, I'm really interested in trying to understand what you're trying to do exactly?
etc, so that the domain/folder path is the effective homepage for a site and all pages hang from that domain/folder.
The upgrade hasn't rendered the existing hostnames table unusable but we can't create new ones without hacking straight into SQL. Sometimes a site will have a unique domain as well as the folder path, but mostly we use ISAPI rewrites to redriect a vanity domain straight to the deep folder homepage.
So you set these domains on the WorldWide node so that the right cultures are picked for each site?
Then starting with 4.11.3 what I'd do is setup one unique normal hostname, www.domain.com, on that node, and then set wildcard domains on each 'EN', 'FR', etc nodes. A wildcard domain is a domain with hostname '*' (a single star) and a culture. So Umbraco would match www.domain.com to WorldWide, then follow the normal path to the page, eg /uk/site-1/en/path/to/my/page, then notice that there is a wildcard domain on /uk/site-1/en and set the culture appropriately.
Am I making sense?
Hacking the domain in the DB _may_ work but I can't guarantee it won't have strange (and nasty) side effects ;-)
Thanks both for getting back to me! Sorry for delay too, symptom of the server problems with our.umbraco
I've replaced my paths with wildcards and BOOM, back in action. What was the reasoning for making this change? The old manage hostname system could be a bit fiddly sometimes but seemed to perform ok, so I'm interested in why it was changed.
There were a lot of discussion at CG12 last year about being able to set the culture independently from the hostname, and in fact it does make quite a lot of things easier... hence the change...
In addition, multiple-level domains such as yours were never meant to be officially supported, and as a result could behave quite erratically and create all sorts of nasty errors... hence the change...
Possible 4.11.1 back office bug - Manage Hostnames dialog
Hi,
I recently upgraded a production and staging instance to 4.11.1 from 4.7.1
.Net 4, Win 8, IIS 7, SQL 2008, No stacktrace.
When using the 'Manage Hostname' dialog to set domain path and language, no matter what I enter in the UI gives an 'Invalid Hostname' error. The domains I'm entering are correct (not invalid) and no record appears in the umbracoDomains table.
I've resorted to manually entering records in the umbracoDomains table but this isn't really a solution for us because non-developers need to be able to manage this themselves.
Have I found a UI bug? The 'Invalid Hostname' message appears instantly and there appears to be no server round trip on the validation.
Any advice gratefully accepted :)
Bill
Hi Bill and welcome to our :)
What is the format of the domains you're trying to enter in the hostnames? And could you perhaps upgrade to 4.11.3 to see if that fixes the issue? I know that there unfortunately where some minor bugs in the mentioned version - however I can't remember if some of them were related to the manage hostnames dialogue.
Looking forward to hearing from you.
/Jan
Hi Bill,
Any reason you're not running the latest 4.11 (4.11.3.1)? I recall some bugs with the Manage Hostname dialog around 4.11. I see a few in the issue tracker that were fixed in 4.11.1, so theoretically you should be fine, but not sure if another fix got slipped in afterwards. Are you able to reproduce this on a fresh install? Maybe something was missed with the upgrade?
-Tom
Hi,
Thanks for getting back to me!
I have upgraded my local instance to 4.11.3 but unfortunately that hasn't changed the issue. Domains are in the format http://mydomainname.com/path/to/the/language/homage. We have 10 active languages in the language selector.
It's odd - even opening up a hostname that currently is ok and resaving that produces the Invalid Hostname issue. I can't recreate this on a fresh installation.
Any other things I should try? Any help gratefully received!
Thanks
Bill
Hi Bill,
I'm getting the same results here. It seems something.com/something works, but not something.com/something/else - maybe it only supports one level?
It might be best to go ahead and report an issue on the issue tracker below, as I'm unsure if this is the expected behavior.
http://issues.umbraco.org/issues
Thanks,
Tom
As of 4.11 valid hostnames only support _one_ level ie www.site.com/foo but _not_ www.site.com/foo/bar so it's "normal" (at least expected) that what you are trying to do does not work. And in fact, I have plans to also remove support for the first level, ie only authorize www.site.com, as the first level is usually used for languages (/fr, /en...) and we have new ways (wildcard hostnames) to support that.
That being said, I'm really interested in trying to understand what you're trying to do exactly?
Stephan
Hi Stephen,
We have about 20 sites, each with multiple languages and grouped into different countries, in one tree. So, we have:
In Manage Hostnames, we have the deep folder set as the culture homepage, ie
www.domain.com/uk/site-1/en (en-GB)
www.domain.com/uk/site-1/fr (fr-FR)
www.domain.com/uk/site-2/en (en-EN)
www.domain.com/uk/site-2/fr (fr-FR)
www.domain.com/france/site-3/en (en-GB)
www.domain.com/france/site-4/fr (fr-FR)
etc, so that the domain/folder path is the effective homepage for a site and all pages hang from that domain/folder.
The upgrade hasn't rendered the existing hostnames table unusable but we can't create new ones without hacking straight into SQL. Sometimes a site will have a unique domain as well as the folder path, but mostly we use ISAPI rewrites to redriect a vanity domain straight to the deep folder homepage.
Thanks,
Bill
So you set these domains on the WorldWide node so that the right cultures are picked for each site?
Then starting with 4.11.3 what I'd do is setup one unique normal hostname, www.domain.com, on that node, and then set wildcard domains on each 'EN', 'FR', etc nodes. A wildcard domain is a domain with hostname '*' (a single star) and a culture. So Umbraco would match www.domain.com to WorldWide, then follow the normal path to the page, eg /uk/site-1/en/path/to/my/page, then notice that there is a wildcard domain on /uk/site-1/en and set the culture appropriately.
Am I making sense?
Hacking the domain in the DB _may_ work but I can't guarantee it won't have strange (and nasty) side effects ;-)
Stephan
Hi Stephan (and Tom)
Thanks both for getting back to me! Sorry for delay too, symptom of the server problems with our.umbraco
I've replaced my paths with wildcards and BOOM, back in action. What was the reasoning for making this change? The old manage hostname system could be a bit fiddly sometimes but seemed to perform ok, so I'm interested in why it was changed.
Bill
There were a lot of discussion at CG12 last year about being able to set the culture independently from the hostname, and in fact it does make quite a lot of things easier... hence the change...
In addition, multiple-level domains such as yours were never meant to be officially supported, and as a result could behave quite erratically and create all sorts of nasty errors... hence the change...
Stephan
is working on a reply...