Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • marcelh 170 posts 470 karma points
    Feb 23, 2016 @ 11:42
    marcelh
    0

    Refactor with Document Type Compositions without losing content

    I am planning on refactoring a site that currently uses document type inheritance to document type compositions.

    Is there a way to avoid losing existing content (several content pages, news articles, events, etc) when refactoring, other than changing the document type? After refactoring the document type contains the exact same fields. The content editor won't notice the difference and I even the cached umbraco.config won't be any different.

  • Dave Woestenborghs 3198 posts 10621 karma points MVP 4x admin c-trib
    Feb 23, 2016 @ 13:14
    Dave Woestenborghs
    0

    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

  • marcelh 170 posts 470 karma points
    Feb 23, 2016 @ 15:07
    marcelh
    0

    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.

  • Nicholas Westby 1883 posts 6259 karma points c-trib
    Feb 23, 2016 @ 16:11
    Nicholas Westby
    1

    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.

  • marcelh 170 posts 470 karma points
    Feb 23, 2016 @ 19:20
    marcelh
    0

    @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... :-(

  • Nicholas Westby 1883 posts 6259 karma points c-trib
    Feb 23, 2016 @ 20:10
    Nicholas Westby
    0

    Oops, yep, I meant "you have to convert every single content node" rather than "you have to convert every single document type".

  • Kevin Jump 1423 posts 9135 karma points MVP 3x c-trib
    Feb 23, 2016 @ 20:06
    Kevin Jump
    1

    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

  • marcelh 170 posts 470 karma points
    Feb 23, 2016 @ 20:45
    marcelh
    0

    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... :(

  • Marc Goodson 909 posts 5881 karma points MVP 4x c-trib
    Feb 25, 2016 @ 09:39
    Marc Goodson
    0

    Hi marcelh

    Yes, it's a pain, it's hard to convert between the two different strategies for creating document types, once you have content in the database!

    With the introduction of compositions a path hasn't been thought through to enable an existing site to easily change it's underlying document type structure to take advantage of the 'flexibility' of compositions...

    In terms of your options with Nicolas's suggestion above, and I haven't tested in 7.4, but in earlier versions 'Change Document Type' would't move content based on compositions, and it depends on how much content you have anyway...

    The second option would be to use something like CMS Import, basically redesign your site from scratch using compositions, and use CMS Import or Content Service to move the content from the old site structure to new.

    or thirdly, hack the database as per my article: http://tooorangey.co.uk/posts/moving-just-keep-moving/

    I've got a bit of a database background so that points me in that direction, just because whilst there would be a few SQL statements for you to write, there isn't huge complexity involved and it would work.

    regards

    Marc

  • Asif Malik 200 posts 336 karma points
    Feb 25, 2016 @ 10:12
    Asif Malik
    0

    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

  • Dave Woestenborghs 3198 posts 10621 karma points MVP 4x admin c-trib
    Feb 25, 2016 @ 10:17
    Dave Woestenborghs
    1

    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

  • marcelh 170 posts 470 karma points
    Feb 25, 2016 @ 10:46
    marcelh
    0

    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 ;-)

  • Dave Woestenborghs 3198 posts 10621 karma points MVP 4x admin c-trib
    Feb 25, 2016 @ 10:54
    Dave Woestenborghs
    0

    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

  • marcelh 170 posts 470 karma points
    Feb 25, 2016 @ 11:08
    marcelh
    0

    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.

  • Dave Woestenborghs 3198 posts 10621 karma points MVP 4x admin c-trib
    Feb 25, 2016 @ 11:23
    Dave Woestenborghs
    0

    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

  • John Bergman 424 posts 976 karma points
    Oct 10, 2018 @ 04:43
    John Bergman
    0

    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)

  • Søren Kottal 410 posts 2504 karma points MVP c-trib
    Oct 10, 2018 @ 06:52
Please Sign in or register to post replies

Write your reply to:

Draft