Umbraco 17 issues: Culture mismatch in Umbraco 17 after upgrade from Umbraco 13

Questions
, ,
1

All the nodes containing BlockGrid and BlockList in Umbraco 13 were visible properly in the backend.
After I upgraded to Umbraco 17, lot of items in BlockList/Blockdrid in different cultures started showing as “Draft” with no content. It means that the content exist in the database for that culture but Umbraco 17 has the issue with culture mismatch. It could not determine that “vary by culture” on the settings level, document type level and property level means different. Eg. If the document level had “shared content”, but block grid level had “vary by culture”. Then the vary by culture overrides for the new content.
Somehow Umbraco 17 keeps on shoeing draft, unless we disable “shared content”, “vary by culture” enable, etc. Somehow, in Umbraco 13 this was not a problem.
Please fix so we do not see “draft” and umbraco 17 looks up other higher level “vary by culture” settings to determine the language, and not show draft but render it with correct culture specific data.

The only solution I see now is to first set the “shared across” and “vary by culture” for every block document type item in Umbraco 13. Only then plan the importing in Umbraco 17. But this is too much work. Please fix this in Umbraco 17. Thanks.

2

What version of Umbraco 17 did you use? I think RC4 has a fix for this:

#20939 Localization: Restores region-specific cultures

4

Umbraco 17.0.0-rc4. Migrated from Umbraco 13.

The problem is that umbraco 17’s blockgrid and blocklist shows the items as “draft” for all languages including English (default) . English content renders on the frontend even if it shows draft, but other languages shows as 0 content for those items. Adusting vary by culture & shared across cultures settings fixes it. Umbraco 17 does not understand which settings should override based on the display.

eg. An element type has “vary by culture” in settings, but it has blockgrid document type set as “shared across cultures”. The item in the blockgrid is also an element with settings as vary by culture, where 1 document type is vary by culture and others are shared across cultures…

Umbraco 17 need to know till the blockgrid level, which setting overrides till the editor level and page render level.

5

Hi @angelrishi

In v.13, you could set up Element Types(The Document Type behind Blocks) to Vary By Culture, but it would have no effect in v.13.

From v.15, Block Level Variance is now supported, meaning a Block can be shared across Cultures, but with individual properties varying for each culture.

It sounds to me you had the Elements Types configured to Vary By Culture in v.13 — and since this had no effect in v.13, you are experiencing a difference, as it does have an impact on the Content in v.17.

To summarize, it appears that the right solution for you is to change the configuration. As you described.

This sentence ,“English content renders on the frontend even if it shows draft” sounds like a bug. Could you please report it as an issue with clear reproduction steps? (here GitHub · Where software is built)

I’m also eager to understand this case fully. The description of this thread gives me an idea, but there are a few points I would like to clarify. Therefore, I would ask if you could describe in detail how to set up a similar configuration.

As in:

  1. What was the specific version number for the Umbraco 13 you were using before? (example 13.6.3)
  2. The configuration of your Document Type
  3. The configuration of the property on your Document Type.
  4. The configuration of the Element Type (Used as the model for a Block)

Thanks, Niels

6

Thanks for your message.

Query 0:
If I have migrated from Umbraco 13 to Umbraco 17, and I change my blockgrid to varient, will the existing content of other languages continue to be there and not become orphans? I hope I don’t have to reenter those again in different cultures by changing blockgrid as varient?

Query 1:
Image Media Picker becomes variant in a blockgrid even if the image media picker is non variant.
Image Media Picker behaves as non variant is set as non variant outside of blockgrid.

Query 2:
I have “LinkCardItem” element under document type containing the “inherited” properties of Title, Image, SubLinks.
So, the child nodes (inheritied properties) are set as varient(varybyculture). The parent “LinkCardItem” where they are used is set as “non variant”.
Now the Parent “LinkCardBlock” element dc contains BlockGRID of “LinkCardItems”.
“LinkCardBlock” dc is also set as varient(varybyculture).

somehow my homepage DC (not element), has a property of blockgrid… and I add “LinkCardBlock”.

So, everything from child dc elements till various parents dc elementtype till homepage is set as variant(varybyculture).
but “LinkCardItem” child was the only one not set as variant.

We fill in the data and all works well - as Umbraco automatically treats it as variant (even if it was not set due to child and parents being varients).
To clean up this, I change “LinkCardItem” as variant.
The homepage backend shows DRAFT now instead of rendering the content. Nothing is there when I client to edit it or add more linkcarditems to linkcardblock.

So, I have to then again change “LinkCardItem” back to non variant, which again starts to render the content and “draft” disappears.

The problem is that in Umbraco 13 the rendering was happening properly with mixed up varients in the clild/parent level in the blockgrid/blocklist.
After migrating from U13 to U17, I start to see drafts at lots of places. So, manually, I had to set those as “non varients” for the content to appear.

This makes migration bad because there is no backward compatability of Umbraco17’s backend/frontend to treat mixed up varients in blockgrid as all varients (even if some are not).
Or there should be a MIGRATION tool. that should be able to fix this.

The problem now is that there is no way to change “non variant” middle child item to “variant” and save and publish, because doing so “draft” appears, so instead of shifting the “nonvariant” child to “variant”, the content is not shifted as variant…

I hope I could explain this.

My desire way:

  1. Umbraco 17 to be backward compatible to treat mixed varients of parent/child as vary by culture so rendering at the backend/frontend works and not show “draft”.

  2. Then a migration tool to be provided if Umbraco team thinks that mixed varients should be fixed to a single varient for the whole child/parent level. So, if someone in the middle of multi child/parent keept some child as nonvarient, the migration tool could help adjusting it.

This would make life if migration from v13 to v17 smoother. (btw, same issue was there with Umbraco 16 I guess.)

Angel
Software Architect
webseamsters.com

7

Hi @angelrishi

It is a very complex topic to describe, and I’m having trouble following the description completely.

But I think this can be solved in a simpler manner:

The ‘problem’, as I see it, is that you had ElementTypes configured to Vary By Culture.
This has no effect in v.13, but gets an effect in v.17. So, in v.13(before Migrating/upgrading), reconfigure your ElementTypes to not vary by culture. Then the upgrade should be smooth and work as you expected.

Can you verify if that works for you?

Thanks in advance

8

Thank you. I will do the needful as suggested by you.
In simple words, this is the problem:

This happens when:

  • The node is culture-variant

  • The property is culture-variant

  • You have NOT saved/published that property in that specific culture in Umbraco 13.

Then Umbraco whispers:
“Ah, this value does exist in the database—but only as a draft for this language.”

This is why you see:

  • Data present in backend database

  • UI shows it as Draft for a culture

  • Because it is NOT published in that culture

even in this case, Umbraco 13 renders the content in the backend and frontend. Umbraco 17 does not.

So, in this case, in Umbraco 17 the Draft appears for vary by culture. So, we have to revert back to the “non vary by culture” (as it was in umnraco 13), which shows the data and draft disappears.

There is no way to migrate that “non vary by culture” to “vary by culture” now (even though the data is saved as variant.

Please ignore if this is sounding complicated again.

I am creating a script to adjust the data directly in the DB by assigninig culture to the null ones. Or, follow the path you described.

Thanks again <3