The blockgrid does't work - it didn't in the previous RC either, and I'm starting to get worried about the testing procedure? It works if you build from source code, but not if you install from nuget? Are you bundling in the correct version of the backoffice? It is this issue again https://github.com/umbraco/Umbraco-CMS/issues/16227 which I filled in 14.0 RC 3 and has since been fixed, which is why I'm so confused to see it in nuget installs @User I have done a minimal umbraco installation with 14.1.0-rc2, setup a single page, an element type, a grid with that element type in it and this is enough to crash everything^

csharp
@using Umbraco.Cms.Web.Common.PublishedModels;
@inherits Umbraco.Cms.Web.Common.Views.UmbracoViewPage<MainPage>
@{
    Layout = null;

    var test = Model.Grid;
}

Please create an issue, and I'll go back to enjoying my holiday ⛺😇

Hi @Kaspar Boel Kjeldsen, we are looking into this issue. It could happen when you build from source, you may have a newer backoffice version than what is bundled with the CMS. It depends whether your git client checked out the specific commit or updated the submodule to a newer version. I am also curious when you say that it has previously been fixed as the issue you are linking here does not indicate being included in any release. Did it get fixed through another issue report?

@Jacob Overgaard I guess it did - because it works in 14.0.0 - I just assumed my ticket got forgotten in the race to get to release 🙂 I feel like I'm going a bit crazy here, because if I do a nuget install of v14.0.0 it works, and it breaks in 14.1.0-rc and 14.1.0-rc2 but WORKS if I check out release/14.1 (or v14/dev and compile the whole thing myself)

that sounds really weird

Agreed

good with some more info on it, I can see one of our devs self-assigned the issue

I have 3 projects setup with this dotnet new install Umbraco.Templates::14.0.0 --force # Create solution/project dotnet new sln --name "V14.0" dotnet new umbraco --force -n "V14.0" --friendly-name "Administrator" --email "admin@example.com" --password "1234567890" --development-database-type SQLite dotnet sln add "V14.0" Just with different version numbers. All of them I've set "ModelsBuilder": { "ModelsMode": "SourceCodeAuto" }, as the only extra setting I create a document type with template called "MainLayout" and an Element Type called "Paragraph" that just has a text field. I then add a grid on the MainLayout and make a "Home" page.

csharp
@using Umbraco.Cms.Web.Common.PublishedModels;
@inherits Umbraco.Cms.Web.Common.Views.UmbracoViewPage<MainPage>
@{

    Layout = null;

    var test = Model.Grid;
}

this then fails on anything not 14.0.0 https://cdn.discordapp.com/attachments/1258344394852012053/1258393574026907698/image.png?ex=6687e1d7&is=66869057&hm=3392087b804d4f499a2c2349d8269ca74fd103b45feb992b607d81a872d40e7c&

Just did a quick test on my own RC2 project and couldn't reproduce. I set ModelsBuilder to SourceCodeAuto and am printing the

GridColumns

. So looks like it's a block grid configuration issue, something is not being saved correctly as you pointed out.

I'll see if I can make a poc with a usync setup or something

thanks, that would be great!

I really hope this doesn't come down to a "I've missed something simple" because then I'll feel very silly but I have a POC now https://github.com/kasparboelkjeldsen/umbraco14.1.weirdness The mystery deepens as everything works fine on a complete usync restore -BUT- if you then create a sub page (I've made the main page able to have itself as children) and add anything in that grid, hit save a publish you get the same error Steps and login are in readme

definitely sounds like something in the Backoffice doesn't save it correctly then

Phew - turns out I'm not crazy https://cdn.discordapp.com/attachments/1258344394852012053/1258705439550607433/image.png?ex=6689044a&is=6687b2ca&hm=e80294b3108b152d3508307d0ebb150f48a2d39f7d61df29dc29a78100ba076d&

Unfortunately I just debunked that on a call with Niels, @Kaspar Boel Kjeldsen . We are shipping the correct and expected files. However, some good news: We were able to replicate your bug using your usync dataset. We should now have something to work with, thanks 🙂

Ok? This mystery keeps getting weirder :/

Replication is good. It looked like a race condition according to Niels, which might explain it working on the source code, which is slower than than the production code