Try our conversational search powered by Generative AI!
AI OnAI Off
Blocks ignore fallback settings
Is this related to 7 or 7.1? I know that EPiServer did changes related to language and blocks in 7.1, you can read the details here:
http://world.episerver.com/Articles/Items/EPiServer-71-CMS-available-in-Add-on-Store/
Sep 30, 2013 12:15
Thank you for the link, but it doesn't seem to mention anything related to the issues we have.
We're using EPiServer 7.1 MVC with patch 3.
Sep 30, 2013 12:42
Ah, sorry, I misunderstood the question.
In your site, is the ContentArea property defined as culture specific or not?
Sep 30, 2013 13:53
The content area does not have a CultureSpecific attribute set, in which case it should default to not specific. In Admin I can also see the property is in fact not unique to each language.
We want to build pages with common elements, and we don't want to add the same blocks for each language of the page.
My original question was probably not too clearly stated. Here's what happens, exactly:
- A regular page, with a ContentArea property.
- 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.
No fallbacks are configured for the site, and this works fine for pages. If a page isn't created in a language, it's simply considered a 404.
Edited,
Sep 30, 2013 14:12
I understand the problem and why you have the setup that you have. I tested this in a local site:
1) In edit mode (on page edit), the block is "grayed out" with message: "This content is not available in the current language"
2) In view mode, the block is visible (even if it does not exist in current language)
Need to investigate this a bit more.
Sep 30, 2013 14:45
Hi Mari,
Did you find any solutions or explanations for this issue? Should I file a bug report?
Oct 15, 2013 10:47
Sorry, I have not had time - I have two sites going live the next couple of weeks so I'm swamped, I'm afraid.
You should try asking support about this.
Oct 16, 2013 12:52
Hi,
We have exactly the same issue - blocks ignore fallback settings setup on Root (content id 1). When I do a translation for a block - it comes with empty fields in edit UI, while on page it is displayed with master language (en in my situation)
Is there any solution reported by support?
Edited,
Oct 24, 2013 11:17
I've posted request to developers support. If I would receive complete explanation - I would share it here
Oct 24, 2013 15:10
Support answered:
"I have logged this as a bug:
#107891: Items in content area are shown even if they are not available for the current language You will find the bug on the same location (http://world.episerver.com/Support/Bug-List/) after our triage team has looked into issue."
I've would hope on solution soon
Oct 31, 2013 14:21
Were currently working on a fix for this bug for the 7.5 release. Depending on the changes needed to fix this, it might be a patch candidate.
Oct 31, 2013 15:11
This thread is locked and should be used for reference only. Please use the Episerver CMS 7 and earlier versions forum to open new discussions.
Does blocks adhere to the language fallback settings defined for the site? It seems they fall back to the master language, even though fallbacks have been disabled.
Here's what I did:
We have a multi-language site. If a page isn't created in a language, it simply doesn't exist and we don't want to render the master (or any other language). No fallbacks are configured, and this works for pages.
But: We also want the same behaviour for blocks. A basic page, with a ContentArea. The page exists in all the languages. But when we place a block, that only exists in a single language, the block falls back to the master language, when the page is requested in another language.
Is this to be expected? Or do we really need to check in the block view if the content actually exists in the current language or if it's a fallback?