I think you will loose content because you will change the structure of your doctypes.

But not 100% sure. You can always make a backup of the environment and try to do it.

Dave

Yes, you do loose the content, as you are removing the original properties from the document type. And, as far as I know, you need to remove the properties because otherwise you can't include the composition that has properties with the same name.

I am looking for a way to preserve the content while still being able to refactor the document types.

Here's an idea (untested). Suppose you have a doctype "Home" that you want to refactor. Create another doctype called "Home 2" that has the changes you want. Then right click on the home node and select "Convert document type" (or whatever it's called). Once you've converted the home node to the "Home 2" doctype, delete the "Home" doctype and rename the "Home 2" doctype to be "Home" (and the alias from "home2" to "home").

That's cumbersome, as you have to convert every single document type. However, it's the only way I can think of that would allow you do some some more significant refactoring.

@Nicholas, you mean by changing the document type for each and every content node?

That's what I have been thinking about, and this works. But this would require changing the document type for a few hundred nodes... :-(

Hi

Marc Goodson blogged about something similar a few weeks ago.

http://tooorangey.co.uk/posts/moving-just-keep-moving/

it does involve db hackery though

I've thought about going this way as well, interesting to read Marc's findings on this. And makes me think I'm not the only one running in to this ;-)

What stopped me from using this approach is that, while it's a nice hack for a single document type, having at least 15 document types inheriting from a single master document type containing about 5 properties each, this would require quite some SQL. Let alone that I have the push the changes to a QA and production site, where Id's will obviously vary... :(

Hi Marcel, this might be a bit long winded, but might be a nice package to make to help people migrate ....

As the new properties will be duplicates of existing one give them an alias suffix eg '_new' So

Old Property -- BodyText

New Property -- BodyText_new

Next create a method which is triggered on publish (or save) and essentially checks if each property has a corresponding 'new' one, if it does copy over the data. Then simply publish all pages

Once done all you content should be migrated into the new properties and you should be able to delete the old ones, and rename your new ones.

This is all theory of course, but let me know your thoughts

This is what I would do :

Create a new doctype for each doctype you want to change.

So current doctype has a alias "Home". Then the new doctype will have the alias "Home_New". Add all the properties with the same name.

Then run a migration to change the documenttype of each node that you want to change.

Maybe use this approach : http://24days.in/umbraco/2015/may-the-tools-be-with-you/

After all has been migrated succesfully delete all old doctypes. And remove the suffix "_New" from the new doctypes.

All in all a lot of work and risk just to change your doctype structure.

Dave

Thanks all for thinking! Nice to see all your different views and solutions!

I looked into Umbraco's export/import document types and uSync export/import routes too, but in both cases the import process guards against adding document properties with the same name. And correct.

I completely missed the Chauffeur route, but this looks promising.

It's work indeed, but sometimes you need to make a payment on your technical debt ;-)

This is a case I would keep on technical debt forever :-)

There is nothing wrong in using doctype inheritance. Especially on a site that already has content.

In still use inheritance in combination with compositions.

Dave

Hahaha ;-)

No, it's not that there is something wrong with doctype inheritance. But the thing is that over time doctypes have changed, and I'm now in the situation that some 15 doctypes inherit from a content-base doctype. About 2/3 of them have other common properties, and for the other 1/3 I don't want the content editor to bother with these properties... And that's only one scenario.

Maybe it's easier to do some backend tweaking to hide these properties for editors in the 1/3 of the doctypes.

Here are some pointers how to do that :http://24days.in/umbraco/2015/umbraco-7-back-office-tweaks/

Here is a package that I haven't tested yet that does this : https://our.umbraco.org/projects/collaboration/backoffice-tweaking/

Dave

Sorry to bump something this old... I don't suppose anyone has a package or other insight that can be had with regards to refactoring the document type inheritance? Is this on the roadmap to improve anywhere (I couldnt find it)

I've just needed to move 2 properties between compositions and have done the following successfully:

1. Locally remove the properties from the old and add them to the new composition (all local content for these properties will be deleted by this);
2. Use Umbraco Deploy or uSync to track these changes, so they can be deployed later;
3. Use the following SQL query on the production database to move the property to the new composition: UPDATE cmsPropertyType SET contentTypeId = 5678, propertyTypeGroupId = 41 WHERE contentTypeId = 1234 AND Alias = 'myAlias'; (where 1234 is the old composition ID, myAlias the property alias, 5678 the new composition ID and 41 the property type group of the new composition). You can retrieve the correct IDs from the corresponding tables and make sure you have a backup!
4. Deploy the changes on the production site using Umbraco Deploy or uSync. Because it can't find any content for the property that's removed from the old composition, it won't delete any content (you can verify this by querying the cmsPropertyData table).

is working on a reply...