https://discord.umbraco.com logo
Join Discord
Powered by
[SOLVED] uSync Migrations packer sanity check
# help-with-umbraco
s
I'm dipping my toes in my first migration after uSync Migration got the packer for exporting the old site including config files. When importing into the new site, and selecting the migration plan for NC to BlockList and Grid to Block List, the migrated content files still have Nested Content looking data, eg.
Copy code
xml
<socialMediaIcons>
      <Value><![CDATA[[
  {
    "key": "aba129ff-6b58-41b0-9970-ec03ed92c8c4",
    "name": "http://facebook.com",
    "ncContentTypeAlias": "socialMediaIcons",
    "link": "[{\"name\":\"http://facebook.com\",\"target\":\"_blank\",\"url\":\"http://facebook.com\"}]"
  },
  {
    "key": "a9eb9e13-3dfc-4cc8-b8f6-65e745ffd38d",
    "name": "http://linkedin.com",
    "ncContentTypeAlias": "socialMediaIcons",
    "link": "[{\"name\":\"http://linkedin.com\",\"url\":\"http://linkedin.com\"}]"
  }
]]]></Value>
    </socialMediaIcons>
Same thing goes with grid content:
Copy code
xml
    <pageContent>
      <Value><![CDATA[{
  "name": "Fuld bredde",
  "sections": [
    {
      "grid": "12",
      "rows": []
    }
  ]
}]]></Value>
    </pageContent>
Is this correct?
k
yeah it's not correct 😞 - is that second file in the migrate folder of the migration ? or the uSync/v9 folder ? (if not have a look for the file in the migrate folder - that is where the conversion goes
s
When I upload the zip, it creates a folder in usync/Migrate/ with the name of the zip, that one contains the folders v8, _site and migrated. I guess the last one is created when actually converted. It's in the migrated/Content folder that I still have the old values. If I look in migrated/ContentTypes and migrated/DataTypes the property editors have been updated correctly
k
yeah they should convert.
it might be worth checking the logs (and maybe turing debugging on for 'uSync.Migrations' namespace.
I would recommend just converting one content item for a test (e.g move/rename the current "content" folder for the migration, have a new one with just one item in) - but keep the contenttype/datatypes etc they are needed for the migration to know its going from grid -> block grid . etc
s
Cool, I'll try 🙂
Copy code
Failed migrating [Umbraco.Grid - pageContent] : Cannot deserialize the current JSON object (e.g. {"name":"value"}) into type 'System.Collections.Generic.IList`1[uSync.Migrations.Migrators.Core.NestedContentRowValue]' because the type requires a JSON array (e.g. [1,2,3]) to deserialize correctly.
Looks like it could be related to nested content in grid items 🙂
It works if I remove the item with a nested content property - I'll go see what bugs the converter 🙂
It seems like it runs through NestedToBlockListMigrator more than once. The error is that at one point the content type alias is missing. I tried putting a breakpoint, and noticed the contentProperty.Value was already converted to block list.
k
😦 - it should be able to cope with that (because its possible to run the same migration multiple times) but it might be that it isn't noticing. or returning the right thing. In theory the top of the migrator should check and if its already converted just go OK, and return
YEah - we do this in BlockGird.
Copy code
cs
// has already been converted. 
if (contentProperty.Value.Contains("\"Umbraco.BlockGrid\""))
{
    _logger.LogDebug("  Property [{name}] is already BlockGrid", contentProperty.EditorAlias);
    return contentProperty.Value;
}
but doesn't look like we do it for Nested to BlockList - it will take a look
(but maybe it shouldn't hit it twice i will have to check)
s
I see - when using Contains, isn't it then possible that it fails if there is a grid in a grid? if the inner grid gets converted before the outer, then the outer will contain "Umbraco.BlockGrid", and not convert? If not, then we can just add the same check to NC to BlockList 🙂
Adding this to NestedContentToBlockList works the same:
Copy code
cs
        if (contentProperty.Value.InvariantStartsWith("{\r\n  \"layout\": {\r\n    \"Umbraco.BlockList\":"))
        {
            _logger.LogDebug("Property [{name}] is already BlockList", contentProperty.EditorAlias);
            return contentProperty.Value;
        }
Although, it probably shouldn't hit twice 🙂 I also get an empty block in the blockgrid with an empty contentTypeKey besides the correct blocks, I have to investigate further 🙂
Copy code
json

  "contentData": [
    {
      "contentTypeKey": "00000000-0000-0000-0000-000000000000",
      "udi": "umb://element/e98cb276939b414b9f549a137484d0cb"
    },
It's because I have a full width section. The migrator doesn't create a content type for this, but apparently it will try to add the layout block anyway
Got it working now - sent you a couple of PRs 🙂
k
woot- i will merge them , Will aim for a new release this week.
a
@skttl I found some interesting stuff regarding the way DTGE encodes grid sections that I had to write custom migrators for. Let me see if I can pull them out into a Gist or something
I was going to write this all up in a blog article, but haven't had a chance yet.
Successfully migrates DTGE with lots of nested content and prevalues from v7 to v10
@Kevin Jump let me know if you want to chat anywhere about the code in that PR. Happy to walk you through it.
m
ooh.. I'd just hit the same issue of nested content in grids.. I have the same with full width sections to.. not sure why we don't get a layout for that.. as we have settings to apply to our full width that can't just be applied to the individual blocks.. so I transform full width to grid:11 rather than 12 with a powershell script on the configs.
also with the convert in place.. do we have to now also perform a content export/import too? if I just have settings conversion for legacy grid to blockgrid.. I end up with empty property.. could have sworn in version 3 migrations it changed the prop and converted without the extra export/import content step?
6 Views
PreviousNext
Powered by