Grid layouts and fallback language

[mhesselberg]

When I set up a fallback language and have a grid set up with only one layout, I cannot get the fallback language content to show up as the grid is never 'empty', since the layout is preselected.

A small side-issue with this, is that if I have a page that have content in grid, but want to empty it, I have to delete all rows, save, and then navigate to another page and back again to actually prompt the layout selection, and thereby get a proper empty grid that can be 'fallbacked'.

Umbraco version

I am seeing this issue on Umbraco version: 8.3.0 and previous.

Reproduction

Bug summary

When I set up a fallback language and have a grid set up with only one layout, I cannot get the fallback language content to show up as the grid is never 'empty', since the layout is preselected.

A small side-issue with this, is that if I have a page that have content in grid, but want to empty it, I have to delete all rows, save, and then navigate to another page and back again to actually prompt the layout selection, and thereby get a proper empty grid that can be 'fallbacked'.

Specifics

• Umbraco version 8.3.0 (I have observed similar behavior in all versions of 8)
• Newest Chrome on Windows 10.
• Have not checked in other browsers.
• No error messages to show.
• I should add that proper Fallback.ToLanguage usage of .Value-method calls are used in the following.

Steps to reproduce

• Set up a language and another language that uses the first as fallback.
• Create a language-varying Grid property on a doctype. Set only a single grid layout on this.
• Create a new page using the doctype.
• Put content in the parent language grid.
• Verify that the content is shown when the parent language page is published.
• Publish the child language page, don't put any content in the grid
• The grid content is empty and not 'fallbacked'.
• Put content in the grid on the child page, and publish it.
• Verify that the child page grid content is shown.
• Delete/empty the child page grid property and publish it.
• Again, grid content is empty and not 'fallbacked'.

To reproduce other issue:

• As above, but use a grid with more than one grid layout.
• Setup content on both parent and child.
• Verify that content is shown when published, as expected.
• Try to delete all grid rows in child page, and publish.
• Child grid has some layout data, and will be empty.
• Navigate to other page in content tree, then back to child page. Notice that you now must select layout. Publish.
• Observe that proper fallback is done.

Expected result

I expected a single-layout grid with no row configuration selected to respect fallback logic. I expected multi-layout grid to not require me to navigate away and back to the page to properly 'reset' the interface and allow a fallbacked version to appear when published.

Actual result

I apologize in advance for misusing the Spanish language for these screenshots whilst having zero amounts of competence in the actual language itself.

Here's the language setup:

Here's the single grid layout setup:

Note: We map the content in the output to Json, as you can see in the following screenshots.

Content of parent language page:

Content of child language page:

As you can see, I cannot get the 'select layout' view of the grid here, as there's only one and it is automatically selected.

Output of the grids - parent first:

And the child, which should be similar - but is empty:

Side-issue

Here's a few screenshots to document the other issue with having to navigate away and back again in the content tree to properly reset a multi-layout grid property and get it published to allow fallback:

First, empty grid layout with empty content, on first load - on the child language page:

This will properly fallback the content from the parent.

When I put some content in the child language page grid, and then try to delete rows configurations and everything again, I cannot get back to the grid layout selection - this is as far I can go:

If I publish at this point, fallback content will not be retrieved from the parent.

If I save the page, and navigate away from it (or simply just reload the page), I get the proper grid layout selection back again:

And publishing this page at this point will again properly show fallback content from the parent.

[nul800sebastiaan]

Hi @mhesselberg, thanks for the elaborate description of your issue!

If I may summarize this, I think the biggest issue you're having is that a grid layout is pre-selected for you which is then stored as a "filled in" layout, right?

I do believe @kjac made this change a few months ago (correct me if I'm wrong). Interesting use-case here that we didn't consider. Would it in any way be possible @kjac to detect that the grid property was not touched and should not be persisted as a filled in item?

[kjac]

Hi @nul800sebastiaan 😄

4177 was an attempt to fix the derived issues with default grid content. It wasn't merged, though.

It's a long PR thread, but my observations from https://github.com/umbraco/Umbraco-CMS/pull/4177#issuecomment-459745267 and onwards are probably still relevant for V8.

[mhesselberg]

@nul800sebastiaan Hey again, any news regarding this issue?

[mhesselberg]

@nul800sebastiaan So is issue followup totally dead on your end?

[nul800sebastiaan]

Thanks for the nudges @mhesselberg - looks like I forgot to label this correct which made it fall off the radar. I haven't seen related issues / questions recently, so we'll have to try and reproduce all of this and see what's going on before I can say something sensible about it. Is this still a problem for you in 8.5/8.6?

[mhesselberg]

@nul800sebastiaan Hey, thank you for replying! I'm actually spinning upgrading one of our customers from 8.3 to 8.6 next week, so I'll give you a heads-up by then

[christophborndigital]

@nul800sebastiaan we're having the same issue on a 8.6.0 instance. The grid appears to be empty in our variant (ie showing "Add a row"), but fallback language grid content is not displayed. We're having to implement the fallback manually, detecting if the grid is empty (like https://our.umbraco.com/forum/umbraco-7/using-umbraco-7/73346-check-if-umbraco-grid-is-empty#comment-309078)

[nul800sebastiaan]

Good to see that there's at least a workaround! This might even tie in closely with https://github.com/umbraco/Umbraco-CMS/issues/8615 and https://github.com/umbraco/Umbraco-CMS/issues/7692 and actually be a modelsbuilder problem.

We'd love to get some help with trying to figure this one out and getting a fix in, if someone reading along would be so inclined!

[nul800sebastiaan]

Note: it seems from #7692 that a fix to the community modelsbuilder project has been made that solves this problem, would be interesting to try out as a separate workaround!

[umbrabot]

Hi @mhesselberg,

We're writing to let you know that we would love some help with this issue. We feel that this issue is ideal to flag for a community member to work on it. Once flagged here, folk looking for issues to work on will know to look at yours. Of course, please feel free work on this yourself ;-). If there are any changes to this status, we'll be sure to let you know.

For more information about issues and states, have a look at this blog post

Thanks muchly, from your friendly Umbraco GitHub bot :-)

[christophborndigital]

Coming back to this, when we first implemented a site with variants, I think we assumed the fallback (to the language set as the fallback language) would "just happen", but we then found that one has to specify it when outputting a property with Model.Value("myPropertyAlias", fallback: Fallback.ToLanguage)

What is the equivalent for outputting the Grid? I cannot see any overload for Html.GetGridHtml that would allow specifying the fallback. Is that missing and would need to be added to fix this issue?

[umbrabot]

Hiya @mhesselberg,

Just wanted to let you know that we noticed that this issue got a bit stale and might not be relevant any more.

We will close this issue for now but we're happy to open it up again if you think it's still relevant (for example: it's a feature request that's not yet implemented, or it's a bug that's not yet been fixed).

To open it this issue up again, you can write @umbrabot still relevant in a new comment as the first line. It would be super helpful for us if on the next line you could let us know why you think it's still relevant.

For example:

@umbrabot still relevant This bug can still be reproduced in version x.y.z

This will reopen the issue in the next few hours.

Thanks, from your friendly Umbraco GitHub bot :robot: :slightly_smiling_face: