Hi Kevin,

The simplest method for this would be to create a "blank" site and take note of it's ID. Then set the IsServerAdminSite=1 for that site in the mp_Sites table in your database. You should then set IsServerAdminSite=0 for the first site.

Your SiteIDs will remain the same but you will achieve the effect of having the blank site as your Admin site.

I definitely suggest you make a backup of your database before attempting this change.

HTH,
Joe D.

Hey guys, I've never had to change site processing in mojoPortal, so just for my own knowledge:

Joe D. posted a workaround I've seen before for changing the admin site via the database, but is the problem that the admin site and the default site can be different? If so, maybe there should be a supported way to change the default site as well (like an "IsServerDefaultSite" database field, or a configuration key that could override it)? Or maybe the distinction should be removed, so the admin site is always considered the default site? It seems to me that either of these would be a better long-term solution than changing stored procedures.

Jamie

Hi Guys,

Its currently working exactly as it was designed to work and really this seems like a very minor issue being made into a more of fuss than it should be. The vast majority of mojoPortal installations are single site installations and they do not require any host name to be assigned to a site. When you install mojoPortal the first site is created during installation and it does not require a host name assigned, but if you want to host multiple sites based on host names you must assign any new host names to a specific site, that is a very simple rule and that has always been the instructions. There is no security issue on this thread and I don't see it as a security issue at all. No protected content is leaked. I do see how it could be an embarrasment if you are hosting multiple customers in the same installation and the wrong site comes up but any embarrasment can be prevented by assigning a host name to a site before creating the dns record, and using IIS host headers also solves the problem if a site is later deleted. I've never recommended hosting multiple customers in a single installation and this scenario is just another example of why I wouldn't do that myself though I know some people choose to do that. In this case both sites are your own but again to me its a minor issue that can be solved easily. It is a natural consequence that if you have a site running on a dedicated ip address and you point a host name to it its gonna show whatever site is running there. I don't see how it could be a huge problem that your other site appears there, the host name could not have been that important if you chose to delete the site before pointing it elsewhere. If it is an important host name that people are using you should keep it pointing at an actual running site. The only difference is you would get a dns error or a 404 if there didn't happen to be a mojoportal site running on that dedicated ip address, and I do not see why one would choose to cause a dns error or 404 for an important host name, that would be just as embarrassing.

The first site created also happens to be configured as a server admin site by having IsServerAdminSite set to true. It simply means that that site is allowed to create child sites and change site settings in child sites. There is no technical reason one cannot have more than one site configured as a server admin site, though in practice it isn't what I would do, but its a separate issue vs a default site.

The only reason there must be some site as a default site is because no host name assignment is required for the first site. It wasn't really designed with a concept of "default site", it was designed to host single sites without any extra configuration needed. It seems perfectly logical and reasonable to me that if you want to host multiple sites in a single installation based on host names it is up to you to make sure the host names are assigned to the correct site. I do agree that if you are going to host multiple sites and especially if you are going to host multiple customers in the same installation, its best to plan ahead and make sure your first site is your own administrative site.

There can also be multiple host names assigned to a single site even in a single site installation, so there is no guarantee that any site exists that has no host names just as there is no guarantee that any sites do have host names assigned. mojoPortal is designed to work in either case.

Resolving the site id from the host name must happen on every single page request therefore the sql to do it needs to be simple and performant, I don't want to add any complex logic there and I also don't want to change the current default behavior right now. if it is changed it needs to not break any existing sites and there can already be installations where site 1 has been deleted and the default site has site id 2 or higher, we have no way of knowing, but I know that my site joeaudette.com uses site id 2 because it was once part of the same installaiton as mojoportal.com but was split into a separate installation and site 1 was deleted from that installation. I'm sure others have done similar things when they needed ot move a site our from a multi site installation.

I've logged an item in our project tracker to consider changing this but for now it is a low priority and I don't want to be side tracked from higher priority things that need to be done. If/when I get around to making a change on this I think it will involve having a default site id in web.config/user.config. The way I would implement it the default would be -1 and if -1 is passed we will actually pass null so that it coalesces to the current logic of selecting the first site id it finds, that way upgrading will not change any behavior but if someone wants to force a specific site id as the default it will be possible.

Best,

Joe

Canonical URL is already available. Take a look at the Forcing a Preferred Host Name document. Just be careful using this, because if it's set wrong you may have to go into the database to fix it.

And thank you, Joe, for the detailed explanation of how and why the "default/unassigned" site works the way it does.

Jamie

I admit, disposable sites was not something I thought about when implementing support for multiple sites. Your scenario is an interesting use case though and I guess whenever we get to adding a setting for a default siteid it will help with that, but I think it is kind of a corner case. I do see how it could be embarrassing if you're doing sites for both sides of the aisle and the wrong one comes up. Might be best to have a separate installation for republican and democrat sites just to be on the safe side. :-D