Anyone who has handled a property editor migration from v13 to v14? I am talking about the context of an upgrade, so when someone using my property editor wants to update/migrate from v13 to v14 I would like my property editor to "just work" without the user having to re-configure anything for the data type. v14 uses schemas and UI's, during migration from a v13 site a new column is added to the

umbracoDataType

table called

propertyEditorUiAlias

. For unknown property editors, Umbraco will just copy the value from the

propertyEditorAlias

column into

propertyEditorUiAlias

. This would mean that the Schema and UI-extensions would need to have the same alias which is not possible AFAIK. Heres a issue with more details: https://github.com/enkelmedia/Umbraco-SeoVisualizer/issues/31 In my case, I'm thinking of adding a migration to the package that would change the value of

propertyEditorUiAlias

to the alias of my Property Editor Ui Extention. I'm I on the right path here or something that I'm missing?

I would have thought there is code in CMS core that must have to do similar work to migrate stuff in core. No pointers in the core codebase?

Kind of, but this code only handles the built in property editors. For all others they will set the new

propertyEditorUiAlias

to the same as the

editorAlias

which is kind of not awesome, if I understand things right: EditorAlias = Property Editor Schema Alias EditorUiAlias = Property Editor Ui Alias Since they are set to the same value we can't register both the schema and the UI as an extention with the same alias. I ended up with this that seems to work https://github.com/enkelmedia/Umbraco-SeoVisualizer/blob/v14/SeoVisualizer/Migrations/V_14_0_0/RenamePropertyEditorUiAliasMigration.cs It would have been better if the core-migration just took the old

editorAlias

appended

Ui

so that the aliases were different. I might be missing something here so that's why I asked 😄

Yeh I haven’t done anything in this area so can’t comment. Be interesting if @Jacob Overgaard or perhaps @Bjarke Berg might be able to comment