It's easier for developers to use it and almost the same for users.
Content-Picker still works, but if you will upgrade your solution to Umbraco 8 for example after some time - you will have more problems then if you will start to use Content-Picker2 right now.
No need to upgrade. Both of them work exactly the same, except they store the data differently. The newer content picker stores a UDI (unique id) indeed of an integer.
This is only try relevant right now if you start a brand new 7.6 site. v8 will know what to do with the old IDs, don't worry.
Is there any configuration on Umbraco to tell the picker to always store the ID insted of UID?
I've made an upgrade do V7.13.5 from V5 and have so many code developed over the Id properties on the pickers. Now, ONLY for the new content picked, umbraco returns UID. But if the content is previous from the upgrade, umbraco is returning the Id.
Does anyone have any advice or code to assist with converting from legacy content pickers to the new UDI format?
I assume that every node property and macro that uses the old pickers (int) would need to lookup the new UID property (using the old integer property) and update it's value.
Has anyone done this that could give us a head start?
Thanks for posting the link. This has literally saved me weeks of work!!
I'm updating an old installation to v8, and need to upgrade all the obsolete editors to their new versions before the db upgrade will run.
I was looking at manually opening thousands of content nodes to save and publish them all after updating the property pickers on the templates, but the chauffeur extension has done all the heavy lifting for me in just a few minutes!
On-development of marketing tools at my company is an in-house effort. Since taking my first tender steps with Umbraco 4.x many years ago we've migrated from 4 to 6, 6 to 7 and now I have the unenviable task of going 7 to 8 and finally cloud.
So why am i writing this now? Well, frankly I'm more than a little annoyed that almost every time Umbraco jumps major versions, upgrading the underlying document and data structure has been a major undertaking.
Breaking changes to any project are inevitable, working practices change, ideas change, code....changes. But fundamentally it should be easy for anyone to make the transition with as few pain points as possible.
So why has it always been so difficult? The answer simply is because the Core team don't put enough effort into writing code to allow customers to transition their projects. It has always been assumed projects don't run for long enough to warrant the effort and therefore it's been down to valiant efforts from third parties to fill the gap....or work it out for yourself!
When I've figured out how to get our current project into version 8 I am going to treat Cloud as a last ditch attempt at some mode of "compatibility between versions" as the core team handles upgrades "better" in the cloud. But i'm suspicious that the jump from 8 to 9 will be no easier despite cloud and it will be file -> new project all over again!
By the time 9 comes along we will be at re-brand stage - and I will be recommending we look around at other CMS products, because this is THE fundamental problem with Umbraco as a product.
(Obsolete) Content Picker
According to the following page, Content Picker is Obsolete.
Does that mean there is a new method to use in its place for the latest version of Umbraco? Should I stop using it for newer projects?
Thanks for helping me understand the terminology.
Hi Blackhawk
Really nice question. I recommend you to use Content-Picker2 for new projects - https://our.umbraco.org/documentation/getting-started/backoffice/property-editors/built-in-property-editors/Content-Picker2
It's easier for developers to use it and almost the same for users.
Content-Picker still works, but if you will upgrade your solution to Umbraco 8 for example after some time - you will have more problems then if you will start to use Content-Picker2 right now.
Thanks,
Alex
On a somewhat related note, what is the process to upgrade any existing obsolete content pickers, without loosing the values set?
No need to upgrade. Both of them work exactly the same, except they store the data differently. The newer content picker stores a UDI (unique id) indeed of an integer. This is only try relevant right now if you start a brand new 7.6 site. v8 will know what to do with the old IDs, don't worry.
Hello,
Is there any configuration on Umbraco to tell the picker to always store the ID insted of UID?
I've made an upgrade do V7.13.5 from V5 and have so many code developed over the Id properties on the pickers. Now, ONLY for the new content picked, umbraco returns UID. But if the content is previous from the upgrade, umbraco is returning the Id.
How can I manage this?
Does anyone have any advice or code to assist with converting from legacy content pickers to the new UDI format?
I assume that every node property and macro that uses the old pickers (int) would need to lookup the new UID property (using the old integer property) and update it's value.
Has anyone done this that could give us a head start?
Hi Robert,
Kevin Giszewski wrote a Chauffeur extension to do this https://github.com/kgiszewski/Machina you could either do that or use it as a starting point :)
Matt
Thanks for posting the link. This has literally saved me weeks of work!!
I'm updating an old installation to v8, and need to upgrade all the obsolete editors to their new versions before the db upgrade will run.
I was looking at manually opening thousands of content nodes to save and publish them all after updating the property pickers on the templates, but the chauffeur extension has done all the heavy lifting for me in just a few minutes!
Oh, nice! Thanks so much!
The only place this doesn't seem it'd work is for macro parameters.
I'm in the same boat on this one.....again!
On-development of marketing tools at my company is an in-house effort. Since taking my first tender steps with Umbraco 4.x many years ago we've migrated from 4 to 6, 6 to 7 and now I have the unenviable task of going 7 to 8 and finally cloud.
So why am i writing this now? Well, frankly I'm more than a little annoyed that almost every time Umbraco jumps major versions, upgrading the underlying document and data structure has been a major undertaking.
Breaking changes to any project are inevitable, working practices change, ideas change, code....changes. But fundamentally it should be easy for anyone to make the transition with as few pain points as possible.
So why has it always been so difficult? The answer simply is because the Core team don't put enough effort into writing code to allow customers to transition their projects. It has always been assumed projects don't run for long enough to warrant the effort and therefore it's been down to valiant efforts from third parties to fill the gap....or work it out for yourself!
When I've figured out how to get our current project into version 8 I am going to treat Cloud as a last ditch attempt at some mode of "compatibility between versions" as the core team handles upgrades "better" in the cloud. But i'm suspicious that the jump from 8 to 9 will be no easier despite cloud and it will be file -> new project all over again!
By the time 9 comes along we will be at re-brand stage - and I will be recommending we look around at other CMS products, because this is THE fundamental problem with Umbraco as a product.
Shame too as it's a gr8 CMS.
is working on a reply...