Developer forum

Any thoughts on this? It's a bit critical for our customer and it'd be great if we could get back to them with anything

Only that steps to reproduce is crazy.

I think our solution to this is to remove the option to edit page you redirect to the same page on another language... Why would you even do this...?

I will have it bugged as 'not important' as you can easily work around it I guess - or do I misunderstand the problem?

BR Nicolai

This was only to show that the redirect logic is the issue and it can be reproduced on a clean solution.

We have a solution where our customer makes all the website changes on the master page of the site, so they don't have to do make the for each language layer.


But our "real" problem is that we've coded a redirect from master site to the best suited language layer based on customer IP location and other criterias.
So an example is when i go to https://www.evasolo.com/, it get redirected to https://www.evasolo.com/da based on my danish IP.
And in some of their campaigns they link to https://www.evasolo.com/products - where the customer then lands on the correct language productlist and so on, i guess you get the idea.

But since a lot of users enter those links - the redirects occurs often. And it makes it extremely difficult for our customer to make changes on the frontpage or productlist on the master page throughout the day, since it just freezes and spins forever.

So there is no direct redirect setup on the master pages, it happens in the backend when the page is loaded.


Best regards,
Mikkel Hammer

Here a snippet of the backend logic if it clears it up a bit further

Ok - custom notification subscriber is important knowledge....

So if you remove this subscriber, you have no issues?

I can see you have great checks for visual editor mode, backend user etc. Good start.

I am not sure I understand what you want us to do? You run this code many many many times. 

I woudl recommend a couple of changes

• PageTitle notification is relatively late in the page process - this means that a lot of content is generated before the redirect happens. Try moving this logic to BeforePreRequestHandlerExecute notification which is much earlier - and after the url has been resolved.
• Store the lookup in session - and use that if present to redirect. That would save you a lot of lookups
• Ensure you have no circular refs. You have try catch wrapper around all your code - including the redirect it self. You should avoid that - remove it completely or at least wrap the internals piece by piece and not the redirect - this could actually be a cause if you have circular stuff - and also redirect causes an exception to abort the thread.
• Do not do new XxxService - use Dynamicweb.Content.Services.* and Dynamicweb.Ecommerce.Services.*

BR Nicolai

Hi Nicolai,

This was what i was trying to "avoid" by showing it can be reproduced in a clean installation with a "standard" redirect, i don't think it's our custom code that's causing the problem so to speak.
The problem is the redirect on the frontend, our visual editor request never hits the redirect logic.
But i'll try to implement your suggestions and see if it changes anything, so thanks for them :)

But i don't know if i've made it clear what the issue im trying to tell is. 
Sorry for the confusion, i'll try to make it clearer below.

It's a frontend request that is causing a totally separate visual editor request to fail. The two requests doesn't have to come from the same PC.
If you enter evasolo.com on your PC and trigger the redirect, at the same im trying to save the visual editor - my request on my PC fails with the error shown.
The two requests shouldn't have anything to do with eachother - doesn't that seem like a major issue?

Best regards,
Mikkel Hammer

QA has reproduced it - I do not understand it yet :-).

We have it under item Devops#12481

BR Nicolai

Thanks a lot both :)