We have a case where the CultureInfo.CurrentUICulture is incorrect in Ajax requests which appear to only occur in our development environment (QA and production both generate expected results)
Here is a specific scenario: CartController.AddVariantToCart (mvc controller POST query)
My dev machine has culture en-GB and the site I am running uses sv-SE. Like in the accelerator, we read out the headers from an ajax query in the RequestModelHandler to determine the channel and from that we can set the CurrentUICulture. During an Ajax query and the AddVariantToCart action, this is works. I see the channelSystemId retrieved from the headers and set the CurrentUICulture to sv-SE. BUT when the code enters the AddVarantToCart method, the CurrentUICulture is en-GB again! Something is reverting the culture back to my system culture.
In a clean accelerator I don’t see this behavior. Of course the 7.6.3 accelerator uses a WebApi AddVariantToCart method and a call is made from react, while our code is still doing it in the Accelerator v5 way. But this being the result of old jQuery calls versus react/fetch calls seems unlikely, and even if moving the AddVariantToCart to a WebApi function would get around the problem, this is just one example and it would be a lot of work to do this for all Ajax calls.
Any thoughts or suggestions? Perhaps someone else with a similar experience who has solved it?
From Litium 7 the Accelerator code a new header was included in all xhr communication, that is the header litium-request-context that contains the channel, page, category and product information so the web api can find the correct settings for the request.
The setting of this data is done by the filters that is found in the Litium.Accelerator.Mvc\Routing folder and the RequestModelHandler for web api requests.
So if you can do something similar and include that in your jQuery calls it should work.
We are doing exactly this already. If I walk through the debugger I can parse out the information, find the correct channel and set the CurrentUICulture accordingly. That works!
But its when I get to the MVC Post method where the culture appears to be reverted.
I have a thought though, could the problem be that the RequestModelHandler is a DelegatingHandler which is a WebApi component? Perhaps actions taken here have no impact on the MVC pipeline?
If it is a MVC controller that is invoked outside the routing of Litium (not mapped to a CMS page) then you need to do similar thing for that request.
The RequestModelHandler are used for WebAPI and RequestModelActionFilter for regular MVC controllers. When the url is matching a page in the websites the culture is automatic be set, if url not is matching any pages Litium does not now what that should be mapped to.
We do have, in this case, both the RequestModelHandler for WebApi AND RequestModelActionFilter for MVC (and RequestModelActionFilter is un-altered from the original Accelerator).
Of course, I can add setting CurrentUICulture here in this case, but it feels unnecessary. If the main MVC pipeline can determine channel and culture in a normal MVC request, why only set channel in an Ajax query calling a MVC Post method?
I’ve used the ServiceDecorator pattern to see what IChannelResolver is retrieving and it is definitely parsing a RouteRequestLookupInfo, so the information is available.
