A small little gotcha came by today as I was working on a multi-site Sitecore solution for sites on multiple domains. I saw a question on Stack Overflow which is in fact a question I needed to know the answer to myself. It had to do with binding a site on both a subdomain and no subdomain for the same Sitecore site of a multi-site solution.
Sitecore’s <site ... /> nodes have an optional hostName attribute to bind that specific site to match on the provided host. This is a filter to determine which site to put in context based on the current request’s hostname. If none match, the last site defined (typically left as the main “website”) will be put in context. The question was about handling both a “www.site.com” host and “site.com” and how the typical hostName="*.site.com" doesn’t handle that (because it only handles any subdomains). Needing to know the answer myself I went to a good friend and fellow Sitecore developer Mark Stiles. Mark has significant experience on large scale multi-site installs so he immediately fired back a simple answer to “remove the dot.” Thus, we get hostName="*site.com". Simple, and it works, since it catches anything before the actual hostname, whether that includes a subdomain and dot or not. So if you ever need to handle any subdomain or none, change your hostName filter to not include a dot. You could alternatively pipe-delimit both the non-subdomain and the catch all subdomain.
Nice tip. Thanks.The other gotcha becomes apparent if you need to secure each hostname with SSL. For that scenario you have to have an IP address for each app as per IIS limitations. Have you tried it?
Thanks,
-Nick
Thanks for this post! I had been struggling adding a second site to a 6.4.1 installation, and adding the * to the hostname filter worked right away for me. I actually defined this filter like this: hostName=”*myhostname*” (substituting the real host names).
-S.
It should be noted that when using the wildcard(*) character Sitecore will then use the Sitecore.Text.WildCardParser class which may catch more than you’ve bargained for, if you have a domain that exists within the second domain. For example: mynewdomain.com.pl will be caught by *domain.com if the site node is first. It’s not exactly what you’d expect unless you’d written it as *domain.com*. Then you’d expect it to catch that case so be forewarned. Using the pipe delimited option may be better for you since you’ll be able to specify exactly which domains you are targeting.
Okay so I’ve logged a ticket with Sitecore about the issue. I believe there is a legitimate bug with the WildCardParser.Matches function. The issue results in two types of mismatches.
The first happens with a pattern like *domain.com.pl where it will be matched to http://www.domain.com. The second will be if you have a pattern like *domain.com* where it will not match http://www.domain.com.pl.
You’ll likely not see it if your domains aren’t closely related but if they are you’ll have to order the sites in order of most-to-least specific pattern.
@Mark Stiles:
The issue with *domain.com.pl being matched to http://www.domain.com doesn’t appear to be related to the use of a wildcard. We have several uses of country abbreviations after the .com (.com.au, .com.ar, .com.co etc.) that get matched to our global domain.com even if there is no wildcard used in either site definition.
If you ever got a reply to your ticket then I’d like to know if it’s something that’s going to be fixed. Our workaround is to make sure .com.xx sites are referenced first in the config, though seeing as it’s an include with lots of “patchBefore” and “patchAfter”s in it this can be easily overlooked when launching a new site.
@Mark Ursino
For the purposes of avoiding “duplicate content” punishment in SEO it’s usually worth ensuring the site runs on a single explicit domain, e.g. using IIS to redirect domain.com to http://www.domain.com.
This can also help with keeping site cookie ownership cleanly defined and configuring third party site management tools (such as Google analytics), which tend to be configured per domain.