Let's say that I have a field called backgroundColor in the editor, which is of type true/false, which determines whether the element is colored or not. The content is published and everything works fine. Then I want to change the field type to a selector where the user would choose between different colors. When I change the field everything is fine and correct. But when I go to edit the document, it reports an error (see picture) that it cannot parse the existing value. I assume that it has a boolean value stored from before and cannot map it to the selector. And this applies to any field I changed, here is just a concrete example.
I tried rebuilding several times, clearing the cache, restarting etc. but to no avail.
This was not the case in the V7 version. When I changed the field type, the old values were deleted, which is logical, but there was no error. Just new editor pops up.
Now I have to actually change the name of the field and lot of code(!).
Anyone else having issues with this? Is there any way to fix this from VS or is it ripe for a bug report?
To check the value for 0 and change it to the equivalent in the new list whenever it is opened in the backoffice
Or
whether this error is fired before that event occurs and in which case it remains an issue.
Previously in V7, it didn't wipe the stored data when a DataType changed, as you could change it then change it back and saved data would still be there, but I think perhaps, it just 'didn't error' when it tried to map the old value to a changed set of options, allowing the editor to update the value and save 'as if it had been blank'... or at least that's my recollection. Anyway that might be something worth reporting as an issue, eg what should be the desired behaviour in this scenario etc...
Hi, thanks for once - I mentioned the V7 because it never happened - but with the V10 constantly.
Yes, I could solve this with custom events before saving, but I think it's too much work and the project wouldn't be able to afford it. But this happens all the time, as the initially defined fields are modified over time at the client's request. The problem is with the news, eg. if there are already 100 saved...
But I will do another test on a completely empty version and then raise an issue...
Error changing existing field datatype
Hi,
Let's say that I have a field called backgroundColor in the editor, which is of type true/false, which determines whether the element is colored or not. The content is published and everything works fine. Then I want to change the field type to a selector where the user would choose between different colors. When I change the field everything is fine and correct. But when I go to edit the document, it reports an error (see picture) that it cannot parse the existing value. I assume that it has a boolean value stored from before and cannot map it to the selector. And this applies to any field I changed, here is just a concrete example.
I tried rebuilding several times, clearing the cache, restarting etc. but to no avail.
This was not the case in the V7 version. When I changed the field type, the old values were deleted, which is logical, but there was no error. Just new editor pops up.
Now I have to actually change the name of the field and lot of code(!).
Anyone else having issues with this? Is there any way to fix this from VS or is it ripe for a bug report?
Regards
Hi Asembli
I'm wondering if you could make use of the EditorSendingContentNotificationHandler
https://docs.umbraco.com/umbraco-cms/reference/notifications/editormodel-notifications
To check the value for 0 and change it to the equivalent in the new list whenever it is opened in the backoffice
Or
whether this error is fired before that event occurs and in which case it remains an issue.
Previously in V7, it didn't wipe the stored data when a DataType changed, as you could change it then change it back and saved data would still be there, but I think perhaps, it just 'didn't error' when it tried to map the old value to a changed set of options, allowing the editor to update the value and save 'as if it had been blank'... or at least that's my recollection. Anyway that might be something worth reporting as an issue, eg what should be the desired behaviour in this scenario etc...
regards
Marc
Hi, thanks for once - I mentioned the V7 because it never happened - but with the V10 constantly. Yes, I could solve this with custom events before saving, but I think it's too much work and the project wouldn't be able to afford it. But this happens all the time, as the initially defined fields are modified over time at the client's request. The problem is with the news, eg. if there are already 100 saved...
But I will do another test on a completely empty version and then raise an issue...
Regards
Yeah, I think you want it to fail gracefully like it used to in V7! so the editors can update it accordingly.
The events/notifications in the meantime might give you a quick viable workaround.
regards
Marc
Exactly Marc. Already raised an issue #14753.
Regards
is working on a reply...