Investingating further, this looks very similar to this issue: http://world.episerver.com/Modules/Forum/Pages/Thread.aspx?id=75560
But according to the bug report, this was fixed in 7.5: http://world.episerver.com/support/Bug-list/bug/107891
Has this suddenly reappeared in 8.6? Can someone confirm?
We are also using ContentAreas that are NOT culturespecific, and we fill them with blocks and/or pages that may only exist in some languages. We also don't use language fallback; we just want the FilteredItems collection to contain the blocks/pages that exist in a the current language branch.
As a temporary fix we perform our own filtering of the FilteredItems collection in our controllers by calling:
ContentLoader.Get<IContent>(filteredItem.ContentLink, ContentLanguage.PreferredCulture)
on each item in the FilteredItems collection. This returns null if a block/page does not exist in the current language branch. But it would make more sense if the FilteredItems collection had already filtered out the blocks/pages according to language fallback rules.
Any help is greatly appreciated.
John
Hi,
We think we have discovered a difference in the way the ContentArea items are being fetched in 8.6 compared with previous versions.
In our views we like to do the following (for various reasons):
After upgrading to 8.6 we realized that this caused an ArgumentNullException on a number of pages:
It turns out that item.GetContent() returns null when a block is found in the FilteredItems collection, but not existing in the current language.
I'm not sure what changed, maybe the ContenteArea.FilteredItems property? I'm thinking it shouldn't contain references to blocks that don't exist in the curent language, but for some reason it does.
Anyway, we solved it by adding a check to see if block is null inside our foreach loop, but this wasn't needed prior to 8.6 and I haven't seen any mention of this function being changed in the release notes.
Is this change intentional or have we discovered a bug?