Localhost Root Url Issues on multi-tenant site
# help-with-umbraco
c
V13.6.0 I have a multi-tenant site, with node1 set to https://localhost:44316/coll and node2 set to https://localhost:44316/uc in the "Culture and hostnames" section. The problem is that if I have a link in either site that is "/" then it goes to https://localhost:44316, which then shows the https://localhost:44316/coll site. It's completely unintuitive. Surely links should stay within their allotted sites. Is this a problem with Kestrel or Umbraco, or can anyone suggest a fix? Thanks.
l
Is node1 the first node in the tree on the root? As far as I know, if Umbraco cannot determine the start node based on the cultures and hostnames, it will take the first node in the tree at the root. If that's the case, fixer are: * Don't use the same domain with a suffix (like /coll), but use unique domains. * Don't have the homepage of the site on the root. We usually have this structure: - Website container -- Content --- Homepage <- this has the cultures and hostnames
c
The structure is :- Content --Home 1 --Home 2 And this is on LocalHost, so can't change that, I'm developing locally. It won't be a problem on the live server because they'll have proper URL's which are different.
l
I think you won't have any issues in that case in your non localhost environment 🙂
c
But I do. I've just tried:- Content --Home 1 (/coll set to en-GB) --Home 2 (/uc set to da) Same result. Clicking a "Home" link ("/") on the second site takes you to --Home1
l
in your development environment, yes. Someone correct me if I'm wrong, but Umbraco works like this: * You have a domain, like localhost:44316 that is mapped to your Umbraco instance * You set cultures and hostnames on various nodes. In your case localhost:44316/coll and localhost:44316/uc. * When a request comes into Umbraco, Umbraco takes the incoming URL and tries to determine the start node of the site base on the URL by checking the cultures and hostnames. * You have NOT mapped localhost:44316. In that case, Umbraco will return the first node of the content tree. So the issues on your local environment is that Umbraco does not know what to do with localhost:44316, because it does not match any cultures and hostnames. Another easy fix would be to simply use localhost:44316 for one of the two sites. However, if you have a proper domain for coll (let's say it's coll.co.uk) and uc (uc.dk), and use those as cultures and hostnames, you will never run into the issue that the root is unknown.
c
So you're saying you can't develop a multi-tenanted site without a machine capable of running IIS locally?
l
If you want to have a link '/', but there is nothing on localhost:44316, that's not gonna work no
But that's the only thing that doesn't 'work'
c
That's a serious issue. Worthy of a raising it on the Issue tracker then. I'm now stuffed, having promised a client to build them a multi-tenanted site. It's too late to re-architect now.
l
I don't see the problem? You can continue with what you are doing? It's just that the link '/ ' does not work the way you want, but everything else is not an issue?
c
Well I can't prove the sites work before pushing them live.
j
If you set one of the sites to
/
and the other to
/uc
then the link on the second one should resolve to /uc - I think the problem is if you are not specifically setting the
/
path it will default to the root node
c
I suppose I could try unpublishing the site I'm not working on at the time.
l
You could just get the URL of the home node instead of hardcoding it to /. In that case it will return /coll and /uc respectively
you could also set the cultures and hostnames to localhost:44316 without /uc or /coll on the site you are working on
c
This is a rubbish situation, tbf
So instead of happily coding an html link "/" I now have to mess about with the httpcontext, etc."Just" for the development environment.
l
to be honest, this is seriously not an Umbraco issue but I think you fail to understand how routing works. You define the start of your website as localhost:44316/col and localhost:444316/uc. How is Umbraco supposed to understand what you want with localhost:44316?
c
I understand what the instructions are that we are given:- "Valid domain names are: "example.com", "www.example.com", "example.com:8080", or "https://www.example.com/". Furthermore also one-level paths in domains are supported, eg. "example.com/en" or "/en"."
The point remains though. How to develop multi-tenanted sites on Localhost.
j
You do it by setting explicit top-level domains as you have done, and then in the frontend you make it to go something like Model.AncesterOrSelf().Url() or however you can navigate to your root node from a subnode and get its url - instead of assuming it will be
/
. That should then resolve to the path youve set within the hostname setting
c
Quite. That's quite a lot of work when you consider this can be in viewcomponents, controllers, etc. I guess this is a side effect of DotNet Core and Kestrel. When I used to develop on Windows (I now dev on Linux) you'd set IIS up with Url's that you'd add to your host file to resolve. Ohhh, now wait, I haven't tried that! LInux uses a host file as well. I'll be right back..... 😉
l
Still, in your original situation everything works are you would expect it to work and Umbraco works as you expect it to work, except when you work around the URLs Umbraco generated and hardcode '/' as a link. This cause you to go outside your website root and Umbraco doesn't know what to do with that domain anymore because it's not set in cultures and hostnames. So just don't use '/' as a hardcoded link or accept that the home button doesn't work 'correctly' in your development environment. That literally the only thing that doesn't work. Having said that, host file or linux equivalent is a good idea ofcourse
c
.... IF you can get it to work! It's odd that within the sites there is one page that has the same name (url()), but the links in each site go to the correct version. It's just the home link. Very frustrating to have to "code" this JUST for the local dev env. Guess I'll just have to. 😦
Turns out:
<a href="@Model.Root().Url()">
fixes it, so not that bad. I'll go and collect my dummy now, which seems to have fallen out of my pram! 😉
11 Views