Do you have a wildcard mapping in site settings hosts? Note that there is no http context when the indexing job runs, so for the UrlResolver to function correctly it needs a host to fall back on. There is however an http context during the event-based indexing, i.e. when you edit content.
Creating my own indexing job for commerce solves the issue, hence the issue seems to be connected to the built in indexing job for some reason.
After a colleague of mine upgraded a client project from Optimizely 11 to 12, there's been quite a few bugs surfacing. However the one I want to ask about here is regarding the UrlResolver not working as it used to before which is causing issues.
In our SearchService and more specifically a QuickSearch, we do something like this:
In the first search of the multisearch, where we search for an article (more specifically the part I point at below).
We go into an extension method for the ArticleVariation with ExtendedArticleData() that looks like this:
Now to the issue, if you follow the trail from the QuickSearch into the ExtendedArticleData you will eventually end up at this code snippet:
For some reason the urlResolver here always returns null. The product variable seems legit, and provides the content link and "en" in this case as the language, but it still throws null.
This happens when clearing the search index, and running a new "Search & Navigation Content Indexing Job", and it only starts returning something other than null if I locate that specific product in episerver and save it. But then, when re-indexing, it stops working all over again. The issue was the same with the product part of the multi search, but in that case I was able to solve it by moving the _urlresolver.GetUrl outside of the extension and do it directly as you can also see up in the MultiSearch.
Does anyone know what might cause this? Do I need to do something different with the UrlResolver? This was not an issue before upgrading to 12 and the code here is basically the same.
Search & Navigation: 126.96.36.199