Items in content area are shown even if they are not available for the current language

Vote:
 

A regular page, with a ContentArea property (not CultureSpecific).
- The page is created in all languages of the site.
- Then we add a block with some text, but the block is only in Danish (which is the Master language).
- When the page is viewed in English, we see the Danish text! I was expecting the block would simply not be shown.

There is a bug from 2013 on this (https://world.episerver.com/support/bug-list/bug/107891) which is solved, but I still get this problem in Epi CMS version 11.11.1.

Any ideas?

#204522
Jun 05, 2019 10:06
Vote:
 

Hi Patrik,

There's a couple of things which spring to mind here. First, have you got any fallback or replacement languages set up which cover the blocks/media folder? Could it be that the blocks are falling back to Danish in the absence of English? Also, are you rendering the content area using PropertyFor or are you rendering the content yourself?

#204539
Jun 05, 2019 15:57
Vote:
 

Thanks for your answer,

I have no fallback langauge configured what so ever. Not on the pages, blocks or site root.

I Render my ContentArea with PropertyFor.

#204559
Jun 07, 2019 7:21
Vote:
 

Hi Patrik,

I've given this a try in an Alloy site and I can replicate the issue, though only in edit mode. For me, edit mode displays master content for all blocks which don't exist in the current language and content in the correct language if it exists. When I preview or view on the site, I see only the translated content (unless I set up a fallback). Are you seeing the issue in just edit mode or in preview/site as well?

I suspect the issue is down to loader options in the contentLoader in that, in edit mode it seems to be using LanguageLoaderOption.FallbackWithMaster but in preview/on the site it seems to be using LanguageLoaderOption.Fallback. I may be wrong on that though that's the behaviour being exhibited. There may be a good reason why it behaves like this but, to me, it looks like a bug so it may be worth raising.

As a workaround, assuming you're using a custom ContentAreaRenderer (such as AlloyContentAreaRenderer from the Alloy site) you could add something like the following:

private Injected<IContentLoader> _contentLoader;

protected override void RenderContentAreaItems(HtmlHelper htmlHelper, IEnumerable<ContentAreaItem> contentAreaItems)
{
    base.RenderContentAreaItems(htmlHelper, contentAreaItems.Where(x => ShouldRenderItem(x)));
}

private bool ShouldRenderItem(ContentAreaItem item)
{
    return _contentLoader.Service.Get<IContent>(item.ContentLink, new LoaderOptions { LanguageLoaderOption.Fallback() }) != null;
}

Basically this will go through the items in the content area and remove the ones which aren't available in either the current language or any fallbacks before rendering.

#204646
Jun 12, 2019 11:33
Vote:
 

Hi Paul,

Thanks for the advice. That seems like a OK workaround but I agree that this should be built in into the standard content area renderer.

However we have now changed tactics and have made the whole property culture specific instead (that was OK with the content editors) so we circumvented this problem.

#204862
Jun 20, 2019 9:38