GetVirtualpath producing incorrect URLs

Nikolaj Skipper Rasmussen

Vote:

Hey Episerver Commerce.

I'm working on an Episerver project, where we are using the Solr Search Provider for indexing. In order to speed up product search, we are indexing the product urls to Solr, so we avoid looking it up in Episerver for each search. This has worked just fine up until now, but for a specific scheduled job, the produced urls have a language specific prefix, which is incorrect.

E.g.
Correct cannonical URL: nl-webshop/390699/390700/390716/390731/390732/1000390325/
Produced errornous, cannonical URL: nl/nl-webshop/390699/390700/390716/390731/390732/1000390325/

We are using Episerver's standard CachingUrlResolver, which is turn is using the (EpiServer.Web.Routing).DefaultUrlResolver. Our code for fetching the url can be seen in the following line:
_urlResolver.GetVirtualPath(productLink, language, new VirtualPathArguments() { ContextMode = ContextMode.Undefined, ForceCanonical = true })?.VirtualPath;
The method is invoked with the following context: Language = 'nl', EPiServer.Globalization.ContentLanguage.PreferredCulture = 'en', catalog defaultLangauge = 'en'.

Now, GetVirtualPath produces the correct url for all of our scheduled jobs, but one, and as far as I can tell, it is invoked with the exact same arguments and context.

So, my question is: Does GetVirtualPath take additional context into account that is not specificied as a function of it's arguments, or am I missing some other problem, which can account for this difference in the produced url?

Thanks in advance for any help! Let me know if further context is needed in order to give an informated response.

Technical information:

Episerver Instance:
CMS: 10.10.6
Commerce: 11.1

All of the scheduled jobs run on the same application server, and Episerver instance.

Using _urlResovler.GetURL results in the same error.

#187879

Edited, Feb 05, 2018 13:55

Quan Mai

Vote:

I actually think that's the correct behavior. The starting point of the routing system is the start page (normally), and /nl/ is the correct path for the NL version.

#187886

Feb 05, 2018 15:43

Quan Mai

Vote:

I actually think that's the correct behavior. The starting point of the routing system is the start page (normally), and /nl/ is the correct path for the NL version.

#187887

Feb 05, 2018 15:43

Nikolaj Skipper Rasmussen

Vote:

Hey Quan Mai, thanks for the reponse.

It's not correct in the sense that it doesn't actually correspond to the URL for the product.

The prefixed URL results in a 404-error, while the non-prefixed URL will route to the product correctly.
This is the case, since the products are rendered on the NL-website: https://www.solarnederland.nl/nl-webshop.
My current understanding is that the prefix would be required if the domain wasn't nl - that is to say that it would look something along the lines of https://www.solar.com/nl/nl-webshop

I'm still not sure what makes the difference for when the prefix is or isn't added, especially when the arguments for the method are identical.

#187888

Edited, Feb 05, 2018 15:48

Quan Mai

Vote:

So are you having sites with different domain, says yoursite.com for en and yoursite.nl for nl?

#187889

Feb 05, 2018 15:50

Nikolaj Skipper Rasmussen

Vote:

Yes, that is almost correct.

We have one website, but different hostnames for that website with different domains, and different primary cultures.

Specifically, we have the following 4 host names for a single website:

Host Name	Culture	Type
www.solar.dk	da	Primary
www.solarnederland.nl	nl	Primary
www.solarnorge.no	no	Primary
www.solar.se	sv	Primary

However, all catalogs are indexed from the same application server. But the indexing scheduled jobs that work, which is to say that they don't add the prefix when calling GetVirtualPath, run on the same Episerver server and instance as the scheduled job that doesn't work.

#187890

Edited, Feb 05, 2018 15:53

Quan Mai

Vote:

I'm guessing here - when it comes to routing it always gets my head spinning, but in the context of a scheduled job it falls back to the root page as the starting point (as SiteDefinition.Current.StartPage would be null at that point). You might want to try to set SiteDefinition.Current.StartPage to correct contentlink at the start of the scheduled job to see if that solves the problem.

#187891

Feb 05, 2018 15:59

Nikolaj Skipper Rasmussen

Vote:

Hey again.

I was under the impression that Episerver would use the configured hostnames when fetching the URL for products on a single-site. However, I came to realize that since scheduled jobs run in an anonymous context, the site context actually has to be set manually, otherwise the DefaultUrlResolver will use a standard context in which the prefixes are added to the product URLs, since no hosts exist.

Adding the following line of code for the execution of the scheduled job fixed the problem:

SiteDefinition.Current = _siteDefinitionRepository.List().First();

Thanks for the help.

#187927

Feb 06, 2018 15:55