November Happy Hour will be moved to Thursday December 5th.

Multi-language website and HTTPS - changing the language in edit mode

Vote:
 

I'm working on a multi-language website with a shared database and blob storage in Azure.

This is the settings from admin mode:

Name: My site
URL https://mysite-dev.azurewebsites.net/

Host Names:

Hostname: localhost:5050
Culture: nb
Type: Primary
Scheme:

Hostname: dev.mysite.no
Culture: nb
Type:
Scheme:

Hostname: mysite-dev.azurewebsites.net
Culture: nb
Type:
Scheme: HTTPS

Problem

In edit mode, if I'm in the English version of a website and I change the language to NB under the Sites tab, I get redirected to https://localhost:5050/EPiServer/CMS/?language=nb, which is invalid URL. I don't use HTTPS on localhost.

The same goes for Norwegian branch. I get redirected to https://localhost:5050/EPiServer/CMS/?language=en

#190013
Mar 29, 2018 11:48
Vote:
 

Forgot to mention that we're using EPiServer 11.3.3.0

#190014
Mar 29, 2018 11:53
Vote:
 

Hey Dejan

Swithing the primary domain to mysite-dev.azurewebsites.net should do the trick as that should be used for edit mode URLs.

David

#190024
Edited, Mar 29, 2018 13:17
Vote:
 

Hi David,

I tried that as well, but it didn't solve the problem.

Changing the language from page header works fine.
https://i.imgur.com/aDwzMyJ.png

#190027
Mar 29, 2018 13:48
Vote:
 

Can you try deleting the localhost entry completely and add a wildcard mapping instead?

#190028
Mar 29, 2018 13:50
Vote:
 

I tried the following settings:

Host Names:

Hostname: *
Culture: nb
Type:
Scheme:

Hostname: mysite-dev.azurewebsites.net
Culture: nb
Type: Primary
Scheme: HTTPS

But then I get redirected to mysite-dev.azurewebsites.net.

A wildcard host cannot be set as the primary host.

#190030
Edited, Mar 29, 2018 14:08
Vote:
 

If you take the culture off the azurewebsites.net host does that work? Episerver will always look to try and map a specific culture to a host name, if one isn’t specified it should fallback to the primary. 

#190034
Mar 29, 2018 14:29
Vote:
 
Host Names:

Hostname: *
Culture:
Type:
Scheme:

Hostname: mysite-dev.azurewebsites.net
Culture:
Type: Primary
Scheme: HTTPS

This redirects me to mysite-dev.azurewebsites.net

#190036
Mar 29, 2018 14:54
Vote:
 

Is this now the desired behaviour? 

#190037
Mar 29, 2018 14:58
Vote:
 

No :(

If I'm running the website from localhost:5050, then I'd like to stay on localhost when I change language from Sites tab.

And if I run it from dev.mysite.no (IIS on a local machine with entries in the hosts file) or mysite-dev.azurewebsites.net, then I'd like to stay on those domains.

#190038
Mar 29, 2018 15:05
Vote:
 

If there are 3 x instances running (assuming with a set of config transforms) then you should be able to explicitly set the uiUrl in the <episerver> section.

#190043
Edited, Mar 29, 2018 15:40
Vote:
 

I appreciate your help.

However, I don't like the idea of doing config hacks.
We want to have ONE config file that works for all developers. If developers want to run the website in IIS and set up custom bindings on their local machine, they should be able to do so without much hassle and having to modify the config file.

As mentioned earlier, changing the language using page header links works fine. I expect the same behavior from the links inside the Sites tab. Being redirected to https://localhost when I'm accessing the site from http://localhost, doesn't make any sense at all :)

Episerver should fetch domain AND hostname from the current context and check if there's a matching hostname in SiteDefinition.Current before redirecting me to some random URL.
It's a bit buggy now and quite annoying, TBH. I hope it's a quick fix :)

Thanks!

#190055
Mar 29, 2018 20:48
Vote:
 

I’m all for making dev life as easy as possible :)! If you want to remove as much friction as possible in the scenario you describe then you could hook into the first request event then use the ISiteDefintionRepository to make the site that matches the first request URL the primary domain and/or set it up as a site. Means DBs can be shared easily and each environment configures itself automatically. 

#190057
Mar 30, 2018 1:10
Vote:
 

just my 2 cents:

  • don't use all the site settings in shared database for different sites if they semantically are not part of the same installation
  • use https locally as well
#190059
Mar 30, 2018 21:11
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.