Import issues for block list and block grid - uSync:Removed in child site - Root site setup

[MrPels]

Describe the bug
I have a setup where one web project serves as the baseline (root), and another web project consumes shared resources via uSync.
The issue arises with the block grid and block list data types.

We have created a new child web project which require that we remove some of the already assigned blocks on the shared data type (block grid).

When we do remove a element the following is added to the local usync file

    {
      "contentElementTypeKey": "0ac1e4db-8a37-467f-9223-95e698efff61",
      "allowAtRoot": true,
      "allowInAreas": true,
      "groupKey": "3f5a81da-4173-41af-aff6-98349cd0da00",
      "label": "uSync:Removed in child site."
    }

This seems to break the Import both manually and also ImportAtStartup and results in that other changes can no longer be synced to the websites.

To Reproduce

The project should run on latest version of Umbraco and uSync.

1. setup a new Umbraco web site and install the latest version of Umbraco and uSync. this will serve as our root site. (see "About the site" section for details)
2. do the same for an additional web site serving as the consuming site.
3. use the uSync settings provided from the section "Additional context" in each respectable websites appsetting,json
4. in the root web site create a block grid data type to produce som usync files.
5. add some blocks to the block grid. Save the changes.
6. run the consuming website next.
7. the block grid and block list data type should now be available.
8. try and make a change to the block grid, remove one of the blocks. Save the changes.
9. this should produce the local usync file. (you should see a label like "label": "uSync:Removed in child site." in the list of blocks)
10. now if you try and manually import usync in consuming website it fails the process.

Expected behavior
The new changes made in root site should be able to be imported in the consuming website. (through magic merge)

Adding additional blocks in the child website works without issue. Therefor we would expect removing blocks in the child website also work in regards to block grid and block list data types.

About your Site (please complete the following information):

• Umbraco Version: 16.2.0
• uSync Version: 16.0.8
• Chrome version: 141.0.7390.55

Additional context

Related to: #747

Root site is configured with the following uSync setting

  "uSync": {
    "Settings": {
      "IsRootSite": true,
      "ImportAtStartup": "Settings"
    },
    "Sets": {
      "Default": {
        "Handlers": {
          "ContentHandler": {
            "Enabled": false
          },
          "MediaHandler": {
            "Enabled": false
          }
        }
      }
    }
  },

Consuming site is configured with the following uSync setting

  "uSync": {
    "Settings": {
      "LockRoot": false,
      "ImportAtStartup": "Settings",
      "Folders": [
        "~/../UmbracoBaseline/uSync/Root",
        "uSync/v16"
      ]
    },
    "Sets": {
      "Default": {
        "Handlers": {
          "ContentHandler": {
            "Enabled": false
          },
          "MediaHandler": {
            "Enabled": false
          }
        }
      }
    }
  },

[KevinJump]

We have a nightly build that fixes this :

https://dev.azure.com/jumoo/Public/_artifacts/feed/nightly/NuGet/uSync/overview/16.1.0-build.20251013.9

will be in next release.

[MrPels]

Hi @KevinJump , i have had the opportunity to test the new release today. I seem to work in the sense of my changes no longer kills the "import" which is great 👍and deleting block elements in the child site seem to work also take effect 👍

But i noticed some strange behaviour with the magic merge i can't wrap my head around.

No matter what changes i do to a block grid/list data type that are provided from the root site, i can't get the correct order of groups. So the result is that the root site groups always display from bottom up, and new groups defined in the local websites are added above them. It does not look like the group ordering is being written to the local/child usync files.
(so in other words - so new groups defined in child site can´t be placed after or inbetween root defined groups).

Also it seems that if we now make changes to block elements in the block list/grid these changes don't appear in the local/child usync files either. Mening at next manuelly Import or ImportAtStartup they fallback to the root definition.

[KevinJump]

yes the ordering when merging is a hard problem. there is no sort order in the blocks, so we don't have a way of saying, what order they come in, other than the order they are in the file. So working out if one should be inserted inside the list is not possible without additional data, which we would have to add somewhere else as to not mess up the blocks. - I will take a look again at this to see if there is a 'simple' solution but i am not sure.

I will check the changes in the child items, i am fairly sure i tested that, but obviously not compleatly.

[MrPels]

The ordering for me is just a "nice to have" feature, but i only noticed it now 😄 so i was just wondering if it was meant to be that way.

Could a simple solution be to write the whole blockGroups section into the local/child usync files in the case of you save the data type in the child project and then respect that list if it exist, when magic merge comparison happens.
I have not looked into the source code myself yet, but that way we would maybe not need additional ordering data, which could make it more complex.

[KevinJump]

Hi,

The PR sort of covers how the updating of items works, but just to say the current behavior is not property-based merging rather block based merging, it sort of assumes you don't change blocks inherited from the root.

Not ideal, but its where it currently is- the PR is us experimenting with property level merging, which is another level, so it might or might not make sense - be the thing we end up doing but we're having a look.

[MrPels]

That sounds great, i will check the branch out in the weekend and see if all the use cases we have with property based changes is covered and give some feedback 🙂

[KevinJump]

Hi there is a build on our nightly feed. if you just want to install and try it on a test site.

https://dev.azure.com/jumoo/Public/_artifacts/feed/nightly/NuGet/uSync/overview/16.1.0-build.20251017.1

[MrPels]

I've been testing the nightly build a bit now. As far as I can see, the property-based merging for block grid/list seems to work well 🎊 👍

• We can now overwrite labels and other settings in the child site if the use case arises.
• Root settings/changes still get pushed to all child sites that use the standard root setup on block elements.
• We can now group the root block elements into child block groups as well.

Findings:

The only thing I noticed was in regards to "areas" settings.
I had defined some areas on a block element in the root site, but noticed they were not being merged in the child site. Looking at the child usync file i saw it had no "areas" section in this case i would have expected it would inherit from the root site.

I did a clean test afterwards where there was no child usync version of the block and "areas" gets picked up correctly from the root site. If i removed areas in the child site the changes would appear and work between restarts of the site.

So in conclusion i don't know if it was something to do with me having a defined label in the child site that somehow blocked the merge of the other settings like "areas" ?

[KevinJump]

Hi,

So what does the child config look like in terms of areas ?

i would expect a child of something that does have areas that haven't been changed to look like this:

 {
   "contentElementTypeKey": "aebadd58-b73e-4be2-969f-0533ba0f5c90",
   "allowAtRoot": "uSync:Inherited from root.",
   "allowInAreas": false,
   "label": "Block Content - Child Label",
   "areas": "uSync:Inherited from root."
 }

I am having a look to see if different combinations can break it.

I am also thinking about sort orders (because it might matter for merged areas) it's a difficult one because we can put an artificial sort order in when the things are serialised - but without the UI (like there is for document type propertiess) we are going to struggle merging orders when there are multiple roots, and if in a child site you change the order of the areas - we can't write back to the root element to say ,well he order has changed 🤔

[MrPels]

Umbraco: 16.3.3
Using uSync: 16.1.0-build.20251027.3

After testing a bit more thoroughly, i noticed that usync does not write changes made in child/consuming website to block elements that was included from the baseline/root website.

It seem to be all settings i try to apply in the child/consuming website that do not generate any uSync file changes.

baseline/root usync file look like so

<?xml version="1.0" encoding="utf-8"?>
<DataType Key="1a758c11-a248-4438-928a-fd87994a69ab" Alias="Shared Block Grid" Level="2">
  <Info>
    <Name>Shared Block Grid</Name>
    <EditorAlias>Umbraco.BlockGrid</EditorAlias>
    <EditorUIAlias>Umb.PropertyEditorUi.BlockGrid</EditorUIAlias>
    <Folder>Shared+Data+Types</Folder>
  </Info>
  <Config><![CDATA[{
  "blockGroups": [
    {
      "name": "Article group",
      "key": "524d94ce-f88e-4b3a-be4a-56d80bbf7ef0"
    }
  ],
  "blocks": [
    {
      "contentElementTypeKey": "e4974ff6-54eb-4677-99e4-2cb3f17a1d04",
      "allowAtRoot": true,
      "allowInAreas": true
    },
    {
      "contentElementTypeKey": "27a06ee3-104a-457a-9543-279079ea9a93",
      "allowAtRoot": true,
      "allowInAreas": true
    },
    {
      "contentElementTypeKey": "6531348d-faaf-4b6d-b59c-7f038d3a78ab",
      "allowAtRoot": true,
      "allowInAreas": true,
      "groupKey": "524d94ce-f88e-4b3a-be4a-56d80bbf7ef0",
      "areas": [
        {
          "key": "4a1ce823-07d3-491a-9252-b981ac2ec7e4",
          "alias": "area",
          "columnSpan": 6,
          "rowSpan": 1,
          "minAllowed": 0,
          "specifiedAllowance": []
        }
      ]
    },
    {
      "contentElementTypeKey": "2ee01282-5c67-4a1f-8896-91e406605f0d",
      "allowAtRoot": true,
      "allowInAreas": true,
      "groupKey": "524d94ce-f88e-4b3a-be4a-56d80bbf7ef0"
    }
  ],
  "gridColumns": 12
}]]></Config>
</DataType>

child/consuming usync file look like so

<?xml version="1.0" encoding="utf-8"?>
<DataType Key="1a758c11-a248-4438-928a-fd87994a69ab" Alias="Shared Block Grid" Level="2">
  <Info>
    <Name>Shared Block Grid</Name>
    <EditorAlias>Umbraco.BlockGrid</EditorAlias>
    <EditorUIAlias>Umb.PropertyEditorUi.BlockGrid</EditorUIAlias>
    <Folder>Shared+Data+Types</Folder>
  </Info>
  <Config><![CDATA[{
  "blockGroups": null,
  "blocks": [
    {
      "contentElementTypeKey": "04940475-62d6-4054-bdab-a2694c3bffd9",
      "allowAtRoot": true,
      "allowInAreas": true,
      "groupKey": "524d94ce-f88e-4b3a-be4a-56d80bbf7ef0",
      "label": "Gallery block"
    },
    {
      "contentElementTypeKey": "464df94f-5d95-44b7-9cdf-00d33e34f911",
      "allowAtRoot": true,
      "allowInAreas": true,
      "label": "Text block"
    },
    {
      "contentElementTypeKey": "0aa8f9ed-8fa6-43fe-9329-ec13294b8055",
      "allowAtRoot": true,
      "allowInAreas": true
    }
  ],
  "gridColumns": 12
}]]></Config>
</DataType>

[KevinJump]

Hi,

yes - i too caught a couple of them while testing it yesterday.

we have a new PR (not yet a nightly) that is simplifying some of this. #838

essentially we are 'just' going to merge the JsonObjects, will a few well known values (like Blocks, Areas, etc) for finding keys etc. and then it works in one way.

this also fixes the missing things and we will drop the "Inherited" value, in favor of just not putting the value in the child file, and anything missing from child that is in 'root' is inherited.

just a couple of small checks and i can make this one a nightly build too.

[KevinJump]

"nightly" version : 16.1.0-build.20251028.2

i think this resolves this if you want to give it a test.