Site resolving without hostname

Question

I have a site definition which is being resolved without a hostName tag set. Do you know what could be causing it to get resolved?

This is what the showconfig of my custom site looks like:

<site 
name="MySite" 
virtualFolder="/" 
physicalFolder="/" 
requireLogin="false" 
rootPath="/sitecore/content/MySite" 
startItem="/home" 
database="web" 
domain="extranet" 
allowDebug="false" 
cacheHtml="true" 
htmlCacheSize="10MB" 
registryCacheSize="0" 
viewStateCacheSize="0" 
xslCacheSize="5MB" 
filteredItemsCacheSize="2MB" 
language="en" 
enablePreview="true" 
enableWebEdit="true" 
enableDebugger="false" 
disableClientData="false" 
patch:source="Sites.config"/>

Notice that there is not port nor hostname attribute associated with it. Also this is the site just above the "website" site.

If I open the site on anonymous tab it does resolve to my site. I also did a test on IIS and added a dummy binding and updated hosts config file. When I opened the url on the browser with the dummy hostname it did also resolve.

This is a local environment. Anyone know what I'm missing?

Answer 1

Seems like "working as intended", no?

I mean - the way Sitecore does Site Resolving is, to work it's way down the list of defined <site> until it finds one that matches. And since your definition is set to trigger on "anything" (virtualFolder and physicalFolder being "/") - it will catch everything that isn't caught by shell and login and so on above.

Your "website" will never be reached.

hostname is not a required attribute. Default "website" doesn't have one either.

Answer 2

when a user visits site using a host name (ex: mysite.com/en), sitecore will go into site definitions, from top to bottom and try to find any matching First site definition for that.

sitecore takes hostname, i.e. mysite.com and language part of the url i.e. /en

sitecore goes to first site definition and check its hostName is equal to "mysite.com" if YES, it directly takes that site definition as current site

if false, AND that site definition doesn't have a hostName attribute define, it match virtualFolder & physicalFolder to "/en"

if that is a MATCH, sitecore also takes that site definition as current site

NOTE: if a site definition have a hostName attribute define, then hostname of the URL request should be equal to exact same, to process virtulFolder/physicalFoder setting of that site definition. if hostname attribute is define and its not equal to current requested url hostname, then that site definition will be totally ignored and moved to next site definition to find a match.

Sitecore has defined "website" site definition in a way, that all the non-matching url request are matched into "website" site definition. i.e. by not having "hostName" attribute and virtualPath/physicalPath are set to "/".

One thing to note is, you need to position the site definitions in such order that, site detinitions that have most conditions should be position first. And the site definitions that are more generic (ex: "website") should be position last in the /sitecore/configuration/sites node.

Answer 3

I wanted to drop a note, in order to hopefully save someone at least some time.

One thing that we just had to work through for a customer that was determined to utilize "virtual directories" instead of unique host/domain names for their Sitecore sites.

In fact, it was submitted as a Sitecore bug back in Feb 2015, but at least as of Sitecore 8.2 (rev 170518) it remains an issue, per this StackOverflow posting: https://stackoverflow.com/questions/28321433/value-cannot-be-null-parameter-name-virtualpath-sitecore

As stated above, you must make sure your sites are entered in the most detailed criteria first, since Sitecore will resolve to the first possible site that meets the requirements.

Now to the meat of the known (Sitecore sponsored workaround): when using same hostname for multiple sites, but differentiating them based on virtualPath="/xxx" you must include the same in the physicalPath="/xxx" attribute as well.

This requirement also applies to the levels of your virtualPath/physicalPath settings, ie: if you have two sites:

one virtualPath/physicalPath located at /xxx/yyyy

It MUST come before the less limiting virtualPath/physicalPath of /xxx