-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add migrators to support DocTypeGridEditor to Block Grid migration #66
Add migrators to support DocTypeGridEditor to Block Grid migration #66
Conversation
…ditorPropertyTypeMigrator
This element type should be configured as settings model on one of the blocks (but this isn't really specific to the DocTypeGridEditor support this PR adds)... |
Hmm, I've just setup a clean Umbraco project with the following package references (using the same Deploy version from the MyGet feed as in this PR and configured a license): <PackageReference Include="Umbraco.Cms" Version="13.4.0" />
<PackageReference Include="Umbraco.Forms" Version="13.1.2" />
<PackageReference Include="Umbraco.Forms.Deploy" Version="13.0.1" />
<PackageReference Include="Umbraco.Deploy.Cloud" Version="13.2.0--rc1.preview.1.g294fdcd" />
<PackageReference Include="Umbraco.Deploy.Contrib" Version="13.1.0" /> I then copied over the 2 migrators from this PR, added the composer and imported the provided ZIP archive: I do see that the ZIP archive still contains the 'Umbraco Block Grid Demo' element types, which causes them to also be added as DocTypeGridEditor allowed element types, but that doesn't cause any issues (even though some have the same name). The only time I've seen the configured blocks come up empty, was when duplicate items were added, but you should see an error in your console if that's the case... If the import completed with a |
Here's what I'm doing... so let me know if I missed something:
|
I followed the exact same steps and get the expected data type configuration 🙃 Can you check whether the UDA file of this data type contains any configured blocks and if it does, whether some have identical |
data-type__ea0ed4c1c48943b89058a70babf430ff.txt Here's the |
… the same content element type
Thanks! I've been able to reproduce this by configuring multiple DocTypeGridEditor grid editors, so I guess you already had one added in a This is now fixed by checking whether the content element type is already returned/added to a hash set, which also means the DocTypeGridEditor configuration of the first grid editor will be used. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All good now with the latest updates... glad you got to the bottom of it.
This PR extends the built-in migrators (coming in Deploy 13.2.0) to migrate the legacy Grid layout using DocTypeGridEditor (exports need to be created using a version that contains PR #65):
ReplaceDocTypeGridEditorDataTypeArtifactMigrator
extendsReplaceGridDataTypeArtifactMigrator
and ensures any DocTypeGridEditor is migrated to blocks using the allowed element types (otherwise they will be migrated to new element types by the default implementation);DocTypeGridEditorPropertyTypeMigrator
extendsGridPropertyTypeMigrator
and ensures the DocTypeGridEditor values are mapped 1:1 to the block item data.I've created a Deploy 13.2.0-rc1 preview version on the MyGet pre-releases feed to test (and ensure this PR builds). Testing by HQ is easier done by copying these files into the latest v13 Deploy codebase.
The migrations can to be added using the following composer:
And to test, I've exported a v8 site using The Starter Kit and DocTypeGridEditor (used on the Biker Jacket product page): export-TheStarterKit-DocTypeGridEditor.zip.