too orangey for crows

Moving, Just keep moving... or how to move your properties when you've mucked up your compositions and doc types

Written by @marcemarc on Wednesday, 10 February 2016

Ok so the scenario here is you've created a Document Type, let's say for a News Article, and you've used Compositions to compose your Document Types,
because you have lots different types of pages with lots of common properties between them.

However your News Articles need to be tagged and you have two different 'tagging' properties that are only used on News Articles, and because they are only used on a News Article, you've created them as properties on the News Article document type itself, rather than an actual 'Tagging Composition'.

All's well, the tagging isn't used anywhere else.

But then suddenly in your agile iterations it becomes clear that there needs to be a 'Video News Article' Document Type for a different kind of
Article, with all the same properties as a News Article but with some extra ones for videos and that.

The Video News Article needs the same tagging properties as the News Article - Nested Document Type Veterans know that you can surely just create your new
Video News Aricle, underneath your News Article, it will inherit all the properties of the News Article, and enable to add your additional Video
properties, along with a suitable video icon - job done.

However in the brave new world of Compositions, this will lock the structure of the News Article document type, and you'll get the message, this content
type is used as a parent and/or in a composition and therefore cannot be composed itself...

or for those of you following along in the lovely new 7.4 UI:

What does that actually mean ? well it means you can't add or remove any compositions in the future from the News Article document type - but it's not unreasonable in this scenario to think you might want to update the News Article again, I mean the client has just invented the need for a Video News Article what else will change ?

So what are the options...

Well you might also think you could just create a new composition, create the tagging properties on that, and add that composition to your two article document types; however these will be new 'different' properties with different ids, and you will lose any data on the existing news article tagging properties that have already been entered.

I think maybe what the message is trying to suggest is that you should now treat the News Article document type as a composition, and create a further new News Article doc type underneath, and migrate all of your existing content from the old News Article to the new one; but it's not a quick fix.

Finally your other more obvious solution is to duplicate the properties on both the News Article and the Video News Article, and it will be fine, but as a developer it
will nag away at you for the rest of your caffeine fueled development days, and when people say the project went well, and the client says they are really
happy with what you've done, you will not be able to enjoy this feedback, because in your heart you know the solution is fundamentally flawed, broken and makes you sad to think of it.

If only there was a way to move the properties from the Document Type to a Composition, without losing the data...

... ok not saying try this at home or anything but.

In the Umbraco database (stop reading now, he's talking about hacking the Umbraco database directly, he's gone mad) the data is stored against the Property
Id, and that Property appears on a particular document type because it is mapped to a ContentTypeId (the doctype) and to a PropertyTypeGroupId (the tab on
the doctype) sooooooooooooo

In the Umbraco Back Office create a new Composition, say _taggingcomposition. Add a tab called 'Tagging' - and update your News Article and Video News
Article to use that composition.

Now connect to your Umbraco Sql Server Db and run the following:

SELECT TOP 1000 [id]
 ,[parentGroupId]
 ,[contenttypeNodeId]
 ,[text]
 ,[sortorder]
 FROM [atgmedia].[dbo].[cmsPropertyTypeGroup]

find your new composition and tab, (it will be the last one), and make a note of the Id and the ContentTypeNodeId for your new composition / tab
combination.

let's say ContentTypeNodeId is 1234
and Id = 66

Find the Id of the property you want to move, using it's alias:

SELECT TOP 1000 [id]
 ,[dataTypeId]
 ,[contentTypeId]
 ,[propertyTypeGroupId]
 ,[Alias]
 ,[Name]
 ,[sortOrder]
 ,[mandatory]
 ,[validationRegExp]
 ,[Description]
 ,[UniqueID]
 FROM [atgmedia].[dbo].[cmsPropertyType]
 where alias = 'aliasOfYourProperty'

Let's say the Id is 111

Now Update the properties entry in the cmsPropertyType table to use the new ContentTypeId and PropeTypeGroupId for your new composition:

Update cmsPropertyType
 SET contentTypeId = 1234, propertyTypeGroupId = 66
 Where id =111

(substituting your values of course)

But nothings happened!

So properties and where they appear are all cached, so we need to trigger the application to restart for Umbraco to become aware that the properties have
moved.

So break the web.config or recycle the app pool etc

And now the tagging properties should appear on the Composition, and in turn appear on both the News Article and the News Video Article; and because the ids
of the underlying properties 'haven't changed' they've never really left the News Article document type, all the tagging data values entered so far
on News Articles remain intact.

So you're all ready for next week's 'Sound Clip Article' right?

... and I'm not saying you're healed and free to bask in the feedback on the project from the client, because even though the situation is resolved,
let's face it, you're still really annoyed and jaded with yourself for not foreseeing this requirement in the first place!

Update August 2018

Dave Woestenborghs (@dawoe21) says: