When Upgrading an old v13 using SEOChecker V13 to V16 (with new SEOChecker installed) I need to specify the property editors on my custom datatypes again. Editor alias was the same. Do I need to run custom migrations to automatically migrate the datatypes to the new V16 standard?? I was assuming the core upgrade functionality tried to find the alias and migrate it to the new datatype like it does for their own datatypes but see it on other custom datatypes as well. So i guess I need to do it manually?

I cheated with ChatGPT and it says: > Umbraco’s core migration system only takes care of its own built-in datatypes when aliases or editors change between major versions. > > For packages like SEOChecker or your own custom datatypes: > > - If the editor alias stayed the same between v13 and v16, the core upgrader won’t touch them – but if SEOChecker (or you) changed editor configurations internally, Umbraco has no way of knowing how to migrate them. > - That’s why you’re seeing them “fall back” to no editor set until you manually re-assign. I am asking the team if that is correct information and not just a hallucination. It also suggested some code, if you want to read: https://chatgpt.com/share/68b84831-5a38-8003-adfc-dccdea9aa0a9

Thanks Sebas, Will check if there is anything else changed. Think not only that propertyeditor.ui and schema alias exists. Will check for differencesa and add that as a migration when needed. Thanks!

I'll let you know when I get an answer from the team!

@Richard Soeteman I'm just inserting my self into this conversations as I'm interested in hearing if your issue would be resolved by the knowledge of Kenns message above. And thanks in advance for investigating with us.

@Niels Lyngsø I've hit this issue too with various packages (including SEOChecker) coming from the latest Umbraco 13 release to Umbraco 16.

To be honest, I checked the source code for this and if still feels really vague what happends in that migration. The issue is that the Umbraco migration always runs before my migration. And the comments in the source code are really weird:

// the V13 "data type split data collector" works like this:
// - if .EditorUiAlias is set, the editor is based on manifests and should use one of the "Umbraco.Plain" options as .EditorAlias
// - if .EditorUiAlias is not set, the editor is based on code and should use its own alias as .EditorUiAlias
// unfortunately there is an issue with the migrator, in that it does not handle manifest based editors using valueType=TEXT,
// but with the above logic in mind, we can work around that :)

I tried to understand it in this forum post, but to be completely honest, I still don't get exactly what happends and why. In my case, the original EditorAlias would become the EditorUiAlias and the EditorAlias would become Umbraco.Plain.String. https://forum.umbraco.com/t/how-to-handle-data-type-alias-change-between-umbraco-13-15/2833

Thanks all and sorry for late reply. upgrading from V13.10 to 16.2 did not resolve the issue. It is also on the Bergmania.Openstreetmap from the starterkit. I will Implement the same solution as Luuk shared. Would have been nice if the core could check the manifest file and had set the ui-alias when the editor alias was found.

That's a shame @Richard Soeteman I think the team would love to follow-up if you have a db before upgrading (v13.10) with the

migrateDataEditorSplitCollectionData

- they'd love to see what's in it! If it exists at all.

Works now with custom migration this is in the

migrateDataEditorSplitCollectionData

Those Aliasses are still used.

[
    {
        "DataTypeId": 1156,
        "EditorAlias": "SEOChecker"
    },
    {
        "DataTypeId": 1157,
        "EditorAlias": "SEOChecker.SEOCheckerSocialPropertyEditor"
    },
    {
        "DataTypeId": 1158,
        "EditorAlias": "SEOChecker.RobotsTxt"
    },
    {
        "DataTypeId": 1159,
        "EditorAlias": "SEOChecker.XMLSitemap"
    },
    {
        "DataTypeId": 1160,
        "EditorAlias": "SEOChecker.Redirects"
    }
]