I was under the impression that updating from MediaPicker to MediaPicker2 and republishing all the content would automatically update id to udi. but have found this is not the case, can anybody confirm if i have to do this manually or why it wouldnt be doing it automatically if it should be.
I don't think it's designed to work automatically when you switch from Picker -> Picker2 implementation, when you change a property's underlying data type - no conversion of the data is triggered.
and Picker2 isn't designed to look for data stored in Picker1 format :-(
and republishing the entire site only, publishes what is already stored in the db, eg the Picker1 format - 'if the migration 'were to work' without dev intervention, then you'd have to load each page on with the new picker2, and repick the items, then save and publish... individually... :-(
They were introduced to help Umbraco Deploy / Courier move picked items between Umbraco environments (the guid ensure uniqueness) -
if you are not using Umbraco Deploy / Courier nor have a need to uniquely identify picked items between different environments, then there isn't a great impetus to migrate them. They use the same UI interface, so there is no improvement to the editors..
But if you do need to migrate them, then there is a gist here where somebody has tackled MultiNodeTreePicker to MultiNodeTreePicker2
Am i right in thinking the actual editor does infact work with Id and Udi. because when i change From MediaPicker -> MediaPicker2 the content and go to edit a page the images still work and when saved here do update to UDI
MediaPicker to MediaPicker2 AKA Id -> UDI
7.6 added a huge breaking change to how certain pickers saved there data changing from Ids to UDI. https://our.umbraco.com/documentation/Getting-Started/Setup/Upgrading/760-breaking-changes#property-editors-storing-udi-instead-of-id-u4-9310
I was under the impression that updating from MediaPicker to MediaPicker2 and republishing all the content would automatically update id to udi. but have found this is not the case, can anybody confirm if i have to do this manually or why it wouldnt be doing it automatically if it should be.
also applies too
Umbraco.MultiNodeTreePicker -> Umbraco.MultiNodeTreePicker2
Umbraco.ContentPicker -> Umbraco.ContentPicker2
Umbraco.MemberPicker -> Umbraco.MemberPicker2
Thanks
Hi Perry
I don't think it's designed to work automatically when you switch from Picker -> Picker2 implementation, when you change a property's underlying data type - no conversion of the data is triggered.
and Picker2 isn't designed to look for data stored in Picker1 format :-(
and republishing the entire site only, publishes what is already stored in the db, eg the Picker1 format - 'if the migration 'were to work' without dev intervention, then you'd have to load each page on with the new picker2, and repick the items, then save and publish... individually... :-(
They were introduced to help Umbraco Deploy / Courier move picked items between Umbraco environments (the guid ensure uniqueness) -
https://issues.umbraco.org/issue/U4-9310
if you are not using Umbraco Deploy / Courier nor have a need to uniquely identify picked items between different environments, then there isn't a great impetus to migrate them. They use the same UI interface, so there is no improvement to the editors..
But if you do need to migrate them, then there is a gist here where somebody has tackled MultiNodeTreePicker to MultiNodeTreePicker2
https://gist.github.com/kiasyn/bb067269d97a37f76e9a0f8743972837
which might be of inspiration.
regards
Marc
Am i right in thinking the actual editor does infact work with Id and Udi. because when i change From MediaPicker -> MediaPicker2 the content and go to edit a page the images still work and when saved here do update to UDI
Well that is disappointing.
The whole reason i am having to do this is to now upgrade to Umbraco 8 which only supports Udi.
I have come across this gist before thanks. might adapt it to work in Umbraco 8 i feel the data is a bit easier to manipulate in that table format.
is working on a reply...