We got the same code running on 3 machines, 2 local and on production server. When we view the google shopping feed on the swedish site all the names, descriptions etc of the products are in swedish except of some “ProductCategory” fields which are shown in other languages.
On our local machines all the data is in swedish but in production the “ProductCategory” fields are in english and after we reindexed the site ProductCategory is in german.
Feels like there is some bug in the base factory when it gets the culture of that property?
We have overriden the factory and it looks like this:
public override PriceAgentItemResult Create(PriceAgentItemArgs priceAgentItemArgs)
{
var website = _moduleCms.WebSites.GetWebSite(priceAgentItemArgs.WebSiteSystemId);
var defaultWebsite = _moduleCms.WebSites.DefaultWebSite;
var result = base.Create(priceAgentItemArgs);
result.ProductCategory = result.ProductCategory?.Replace("-", " > "); // Replace separator for categories
.....
}
We dont do anything with the category except replace the dashes. This has worked perfectly before and I’m suspecting it might be a bug in a recent Litium release.
The Google Shopping Feed is using the property priceAgentItemResult.Properties["GoogleProductCategory"] for the category information and not the result.ProductCategory.
To be able to help out more we need to know how the setup of websites including domain name structure (not needed to have the real domain name but the some example how your sites are configured).
To be able to help out more we need to know how the setup of websites including domain name structure (not needed to have the real domain name but the some example how your sites are configured).
The default Litium.Web.Products.PriceAgents.IPriceAgentItemFactory is registered as Transient in DI engine and in your implementation you are changing this to Singelton because your attribute is not having any lifetime assigned.
You should be able to remove then [Service]-attribute and the DI engine should find your implementation anyway because it inherit the interface IPriceAgentItemFactory that is automatic registered.
In the default PriceAgentItemFactory it exists an cache for the category names and now the cache will be shared between all the different websites.
@patric.forsgard it seems like the problem has returned. We’ve drawn the conclusion when the PriceAgentItemResult.StockStatusDescription is “out of stock” the category name changes language.
Its not the out of stock message that is incorrect. Its the product categories that gets translated. But that seem to happen when the products are indeed out of stock. I tried with your code, but that didnt change anything.
Something in the code is changing the culture on the current thread, this is making the categories to return the name in wrong translation. Where the code that is changing the culture on the thread during the execution is hard to tell.
I think you need to debug your code to see what is happening. What I can see when I check on the assemblies is that you have a lot of own modifications that you need to fix.
Example is this static variable that will hold a static IPriceAgentItemFactory between all the request independent of the entered website that will cause the cache that I talk about earlier to be shared between all requests.
I re-factored everything so no static objects are being used. That was a misstake in the first place. However the problem remains.
new XElement(ns + “availability”, priceAgentItemResult.StockStatusDescription) when this results in “out of stock”
new XElement(ns + “product_type”, priceAgentItemResult.ProductCategory)<-- product category end up being in a language not for the current website.
So i finally found the problem and it had nothing to do with what we discussed before. It was actually creating priceAgentItemResults without making sure the product was published for the current site priceAgentItemResults.Add(_priceAgentItemFactory.Create(new PriceAgentItemArgs(baseProduct, variant, websiteId)));
When running this code on an unpublished product for the current site, it seems that the url gets taken from a random other site that has the product published.
@patric.forsgard i let you decide if this should be considered a bug or not.