Skip to main content
added 307 characters in body
Source Link
Gatogordo
  • 20.3k
  • 2
  • 39
  • 100

I did some investigation and found it is caching indeed. If I clear the caches on /sitecore/admin/cache.aspx the code is triggered again (once).

As the "code:" datasources is resolved in the resolveRenderingDatasource pipeline I checked that one and saw a GetCache and SetCache processor. So yes, that data is cached. And no, the language is not part of the cache key (thx dotPeek).

We have a ticket open with Sitecore support to fix this - but in the meantime we are able to turn off the cache to fix the issue temporarily: there is a setting called XA.Foundation.LocalDatasources.ResolveRenderingDatasourceCache.Enabled - if you set that to false the cache won't be used anymore and the PageList works in a multilingual environment with our coded source.

Update: The final solution can be found on my blog as well: overriding the GetFromCache and SetCache classes in the resolveRenderingDatasource pipeline to generate a language-dependent key does the trick.

I did some investigation and found it is caching indeed. If I clear the caches on /sitecore/admin/cache.aspx the code is triggered again (once).

As the "code:" datasources is resolved in the resolveRenderingDatasource pipeline I checked that one and saw a GetCache and SetCache processor. So yes, that data is cached. And no, the language is not part of the cache key (thx dotPeek).

We have a ticket open with Sitecore support to fix this - but in the meantime we are able to turn off the cache to fix the issue temporarily: there is a setting called XA.Foundation.LocalDatasources.ResolveRenderingDatasourceCache.Enabled - if you set that to false the cache won't be used anymore and the PageList works in a multilingual environment with our coded source.

I did some investigation and found it is caching indeed. If I clear the caches on /sitecore/admin/cache.aspx the code is triggered again (once).

As the "code:" datasources is resolved in the resolveRenderingDatasource pipeline I checked that one and saw a GetCache and SetCache processor. So yes, that data is cached. And no, the language is not part of the cache key (thx dotPeek).

We have a ticket open with Sitecore support to fix this - but in the meantime we are able to turn off the cache to fix the issue temporarily: there is a setting called XA.Foundation.LocalDatasources.ResolveRenderingDatasourceCache.Enabled - if you set that to false the cache won't be used anymore and the PageList works in a multilingual environment with our coded source.

Update: The final solution can be found on my blog as well: overriding the GetFromCache and SetCache classes in the resolveRenderingDatasource pipeline to generate a language-dependent key does the trick.

Source Link
Gatogordo
  • 20.3k
  • 2
  • 39
  • 100

I did some investigation and found it is caching indeed. If I clear the caches on /sitecore/admin/cache.aspx the code is triggered again (once).

As the "code:" datasources is resolved in the resolveRenderingDatasource pipeline I checked that one and saw a GetCache and SetCache processor. So yes, that data is cached. And no, the language is not part of the cache key (thx dotPeek).

We have a ticket open with Sitecore support to fix this - but in the meantime we are able to turn off the cache to fix the issue temporarily: there is a setting called XA.Foundation.LocalDatasources.ResolveRenderingDatasourceCache.Enabled - if you set that to false the cache won't be used anymore and the PageList works in a multilingual environment with our coded source.