https://discord.umbraco.com logo
Join Discord
Powered by
uSync Migrations DTGE Grid > Block Grid
# help-with-umbraco
i
I think I'm getting myself in a pickle here!! I have an U8 site with DTGE grid content. I've installed uSync Packer, and created a zip file from the backoffice (I have to manually add my content configs to the zip as their missing) In the V13 site, I've installed uSync Migrations and uploaded the zip file. I can see the migration in the Existing Migrations list, Site Files is ticked, BUT Converted is not. Do I "need" to convert the files, I thought that using V8 usync files, meant that I didn't need to convert them? I have tried converting, and then running an uSync Import, but this doesn't seem to work very well. I don't see any Grid Layouts or Row configs, and when I try to load the front end I get a "item with the same key has already been added" error from the internal Umbraco BlockGridPropertyValueConverter
m
Must admit I got a lot of errors with trying the packer route. And ended up having an interim 10.8.6 site just to migrate the db and then use usync migrations to convert in place. And then finally a v13 site to then point at the 10.8.6 migrated content db to do the final update.
i
the site and DB has already been converted from V8 > V10 > V13. Without migrating, the DTGE Grid properties all display the correct content, and the front end works. But when I pull in the packed zip, and run the migrations to convert from DTGE to Block Grid, it breaks all the grid properties, and the front end fails to load.
m
so you have the dtge 12.1.0 nightly prerelease package in v13?
and it should break it.. as you'll be converting dtge over to blockgrid? so you need to remove all the dtge stuff and replace with blockgrid implementations?
(though guess depends what you mean by breaks it.. do you see blockgrids in the backoffice where your legacy grids with dtge used to be?)
i
I have the dtge 13.1.0-prerelease package installed, and the files in the App_Plugin folder
m
Ooh 13.1.0 didn't know about that one? not on nuget... where'd you find it? https://www.nuget.org/packages/Our.Umbraco.DocTypeGridEditor/12.1.0-blackknight001#versions-body-tab
i
b
I done DTGE from v8 directly to v13 so not sure wh would you go v10 on the way to it 😕
m
beacuse.. umbraco core migrations are only between lts
b
dont use umbraco core migrations, you use either usync or core migrations 🙂
m
so v13 doesn't retain v8 => v10 migrations
b
you dont do v10 migrations at all...
with usync migrations you do v8 -> v13 directly
m
only if you want to migrate into a new v13 vanilla site
b
not really 🤷‍♂️
m
which means you loose all your umbraco forms entities
b
not really 🤷‍♂️
i did migration v7 directly with keeping all forms, users and content ;p
m
usync supports the forms.. but not the entries posted against them
at least that's my experience
also loose all the audit history..
??
b
yeah you loose audit history, but v10->v13 is not something what i did test and based on your comment seems like it doesn't work well
m
I didn't pack... I migrated in place. 🙂
just thought of another gotcha.. v8 site had to have the latest uSYnc v8 version.
i
@Mike Chambers can you explain that a bit more please? I've only used the packer so far
b
what i personally recommend is do fresh db with v13 as there is a lot crap left after core migrations 😂 sadly umbraco is not cleanest cms when it comes to database
m
as you have a v13 site that has all the requirements (eg dtge is working) you can use the usync migrations backoffice to say migrate in place instead.. (it acts on a usync\v9 folder in your v13 site)
and then apply the migrations directly.
b
if you need only change one editor you might want disable all other migrators than dtge one ;p
i
@Mike Chambers so do a full usync export from V8 site and move those files into the V13 usync folder, then migrate in place?
m
nope you can just do a clean export in v13 to regenerate all the usync files needed
it acts on the v9 usync files. in your v13 site..
b
@Mike Chambers slow down, lets ask few questions first
m
I think the packers are more for what bielu is advising if you want to start with a clean v13..
b
@Ian Houghton did you start fresh site in v13 or did you upgrade you v8 to v13? if you did fresh start you shouldn't use way which Mike say about v10 migrations, v8 directly to v13 would work but maybe you need adjust config: https://github.com/Jumoo/uSyncMigrations/pull/261 If you did upgrade to v13, you would point as Mike mentioned as just target DTGE migrator and disable all others
also there are other question, like does your site vary by culture? if yes there is chance it wasn't tested!
i
yes, the site DATABASE was upgraded from V8 > V10 > V12 > V13, then the code was upgraded to .Net 8. Site runs fine in this state.
b
then you do just migrator to dtge as Mike and me suggest 🙂
i
but now trying to convert existing DTGE Grid content (that is currently Grid layout (legacy)
ok, will try that next
b
you do full content export on this, but in this case you will lose roll back option just be aware of it!
i
i have many db backups !!
b
then you enable grid and dtge migrator and do migration on top of it 😉
m
you can also have migrators for any legacy mediapickers etc.. that might have come along for the ride in v8->10>13 though that is a little more involved.. and had issues for us that needed a forked usyncmigrations.
b
@Mike Chambers why didnt you pr back to migrations than if you had fork? 🤔
m
because it was very bespoke.. and not really a generic use case.
i
is there a config file for migrations to turn stuff on/off ?
m
you create your own migration profile.. or you can use the existing grid->blockgrid and nested conent-> block list one that in in core
b
m
b
but yeah I will most likely doing migration block to block grid soon 😂 that will be fun
m
b
he will need to setup migrators to be v13 as well which will be fun!
m
don't think I had to do anything.. for grid to be converted..
b
okay then maybe it changed at some version of migrations as i remmber i had to setup v8 on some migrators from v7
m
was more for if wanted others included by adding a 
[SyncMigratorVersion(8)]
b
oh yeah maybe because i imported migrators which weren included in v8 by default
m
Yeah it wasn't a quick and easy process.. and each site I've done has thrown up new challenges.. property value convertors hiding age old values etc..
but at least a migrator can be added to use those convertors...
i
@Mike Chambers the plot thickens. so using the "Convert this site" method on the current usync files, seems to work better. Running the migration updates the Grid datatype, fine....... but as soon as I save an existing Doc Type (nothing to do with grid content), then the newly created grid doc types i.e xxx\Models\BlockGridLayout_Content.generated.cs get deleted, and when I reload the datatype again, its broken. What am I missing ?? performing the migration again, recreates the BlockGridLayout_Content.generated.cs and others, and the datatype starts working again.
b
Sounds like migration wasn't applied did the sync files got updated? Do you have running usync at startup?
i
Usync is disabled at startup
If I watch Git, I can see the Blockxxx.cs files get created after migration, but after saving any other doc type, they get deleted by modelsbuilder (when clicking the regenerate models button in back office)
b
I think it is because usync files are update but they are updated in separate directory post migration 🤔, i didnt done migration on same version yet, so Mike will need support you here 😉
m
Yep, so process AFAIK.. convert in place.. produces usync config files (guid based) in the 
usync\migrations\{your named}
folder.. You then complete the migration with import via the usync migration dashboard.. At this point your DB is updated but your uSync v9 folder isn't (it still retains the pre migration config files) You can then go to usync normal dashboard and do a clean export all, to get those updated to the current DB state. (or just settings... whatever you require)
However, as to models builder causing the newly generated models to be deleted and not now as the DB state.. is something I've not encountered.. (if you aren't recycling at any point in this process, I don't see how usync/deploy etc can be doing anything) I'm using 
SourceCodeAuto
for models builder and generating models into a separate class library...
i
@Mike Chambers so this is now my revised process: 1) run my V13 site and perform a uSync Clean Export (creates a V13 folder) 2) create a "Convert Nested Content to BlockList and Grid to BlockGrid" migration using Convert in place and add my _site folder from old site 3) let uSync migrate the files (i can see a V8 folder being created) 4) then Import the Settings only at this stage 5) load the Settings section, I can see the new BlockGrid setup ok 6) run another uSync clean export, everything is still ok in the backoffice at this point 7) then click on "Generate models" button in the backoffice, as it states the models are out of date (we're running in SourceCodeManual mode) 8) I can see a bunch of new doc type .cs files generated, all associated with the new grid layouts etc 9) go into backoffice and change any other doc type, click save, then regenerate models. The same Grid .cs files have now been deleted and the grid break 😠
Run the migration import again, back comes the Grid, models are out of date, so "Generate models", and hey presto, back come the .cs files.....
I've noticed that none of the new Grid Layout document types i.e BlockGridLayout_FullWidth.cs are created in the backoffice in the document type section, I can't see them anywhere. It's like they not being persisted to the database
m
so the v8 folder created is... 
\usync\migrations\v8\contentTypes
as you've set the migration profile to be called v8? when you run your usync clean export at this point.. are the new doctypes in the 
usync\v9\contentTypes\
folder?
i
No. At the point that the grid is "working" in the backoffice, if I do a clean export, there are NO usync files relating to any of the new BlockGridLayoutxxxx doc types in either the 
\usync\migrations\v8\contentTypes
or 
usync\v9\contentTypes\
usync folders
Ah, I might have found the culprit, one of the migrated xml files for a BlockGrid doc type didn't have a value in the element, so the others got "created" but the process mustn't get completed because of the error. Adding a value to Name, and rerunning the migration has created the missing usync files. The new BlockGrid doc types are now persisted as well. Now onto the Content !!!
Is this what you would expect to see when doing a full import. I can see the 57 doc types that will get changed, but content is showing as "1" but in the dropdown it says 1356/2080 changes ? There are 2080 config files in the 
uSync/Migrations/v8/Content
folder https://cdn.discordapp.com/attachments/1268891607265185836/1270296894895292518/Screenshot_2024-08-06_at_09.23.57.png?ex=66b32fac&is=66b1de2c&hm=571238f154dbe2b7668c7ec1397dd2eec6c2c8baf86a72474f6540d43ee2b8c7&
m
I think you can click on ContentHandlers to show you the individual content lis for changes and see any errors/changes.
but yes that looks about right.. (ps as you've migrated the db I think you can exclude media to speed things up.. unless you have custom media types with grid or nested content 😉 )
i
@Mike Chambers really appreciate your help with this. The settings/content have been migrated, just need to sort out all getting the styling into the new Grid partials !! but thanks
220 Views
PreviousNext
Powered by