Change a Document Type Missing in Umbraco 8

[mathewknott]

I've posted the following on the forum

https://our.umbraco.com/forum/umbraco-8//96476-change-document-type-in-umbraco-8

--
I've noticed in Umbraco 8 there is no option to "Change Document Type" when editing a page in the tree (Under the menu Do Something Else).

Does anyone know if this feature will come back or if it's gone for good or if kind of work is recommended now to be handled in a different way.

It was a very handy and useful feature. I had feedback. I've copied the text below..

Hi Mathew It seems the action exists here, but has been commented out for now: https://github.com/umbraco/Umbraco-CMS/blob/dev-v8/src/Umbraco.Web/Actions/ActionChangeDocType.cs I guess it is because the old one was using WebForms and it needs to be re-written with Angular + Web API in Umbraco 8. The other actions have Angular views and controllers, which exits here: https://github.com/umbraco/Umbraco-CMS/tree/91c52cffc8b7c70dc956f6c6610460be2d1adc51/src/Umbraco.Web.UI.Client/src/views/content It would be great if you submit an issue here: https://github.com/umbraco/Umbraco-CMS/issues /Bjarne

[bjarnef]

@mathewknott you should probably update the title to "Change a Document Type" instead of "Create a Document Type".

[mathewknott]

@mathewknott you should probably update the title to "Change a Document Type" instead of "Create a Document Type".

Thanks. Done.

[bjarnef]

@kjac maybe this is something you want to have a look at? 😁😎🤓

[kjac]

Geez Louise that's no small feat. I will ponder it for a few days 👍

[clausjensen]

The feature was chosen not to be ported to v8 initially, as it was basically creating more issues for people than it actually fixed.

The short explanation is that when you change a document type of an item, you basically also get to decide what happens with the data stored in each property (what new property does this data get mapped into). Since this is a one-way-one-shot operation that happens when you do it it is not as such stored in any sort of history and we have no idea what you actually did, after you do it.

Considering this in a Umbraco Cloud scenario - if you had this item already deployed to your destination, redeploying the item where you have now changed the document type, things simply no longer match up:

We have this content item that is of type x .. and now you're trying to send me this same content item, but it is now of type y? - things aren't really matching up - I don't know where to put this data?

A solution could be to simply say - well .. if there's a mismatch between the existing item's doctype and the doctype of the item being deployed ... it is most likely the one being deployed we want to keep so we just delete the one on the destination and put up the new one with the correct properties.

In theory this should work. Then there's however some cases that we need to handle, such as .. what happens if this particular node has children? - we can't delete it then without temporarily moving the children elsewhere.

So based on the fact that this is potentially creating big issues for people in Cloud, we would (for now) rather that you either manually replicate your data over to a completely new node of the wanted doctype - or if you have a lot of content where you need to do this - create a script for moving data to new nodes of the new doctype.

We would however like to bring back this feature in the future - it has just not been prioritized yet. I'm marking this as a feature request, but until we have a decent solution that will not have people end up in bad situations on Cloud, I don't think we will be prioritizing merging anything in.

[kjac]

I did a brief investigation of this and it really is a hornet's nest once you open it up. Specifically language variance makes it a really troublesome feature to implement in a way that makes complete sense to editors.

[clausjensen]

@kjac oooh yes... I hadn't even considered that part. So.. yep.. my recommendation here is that noone should spend time working on this, as there will likely be a lot of unconsidered scenarios causing this to end up as a feature that will not get prioritized and merged for a very long time - which is just a bad experience for everyone 😢

It will hopefully some time in the future, be picked up by Core again with a proper process to make sure we cover all things.

[mathewknott]

Hi I build a lot of sites (small and large) for the agency and they choose to self host rather than the cloud. I understand your issues with the cloud but may I suggest this could be a configurable feature? Maybe disable it by default for the Cloud? In designing doc types and fields, we have clients changing their minds all the time, and very often in the build stage of the project the way I initially design the doc types need to change as the way I built it initially doesn't make sense. It's a pain to delete and recreate content, rather than do this quick change of doc type. This was a great feature that was introduced in v7. I'd ask the question, if the ability to change a doc type is possible and there in code, then I don't personally see a risk of the user having the option of enabling or disabling the feature of adding a doc type. Especially if the issues being raised are for concerns for only Cloud hosting and not self hosting.

…

On Mon, 1 Apr 2019 at 08:26, Claus ***@***.***> wrote: @kjac <https://github.com/kjac> oooh yes... I hadn't even considered that part. So.. yep.. my recommendation here is that noone should spend time working on this, as there will likely be a lot of unconsidered scenarios causing this to end up as a feature that will not get prioritized and merged for a very long time - which is just a bad experience for everyone 😢 It will hopefully some time in the future, be picked up by Core again with a proper process to make sure we cover all things. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5070 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEV9hRO9hkynfRd2Fd7iNZAEiO51c3iBks5vcfrlgaJpZM4cHG3e> .

[kjac]

As is the code from V7 is by no means sufficient for V8, taking into account the complexity of culture variance.

Until a solution can be thought up that doesn't cause irrevocable data loss in conversion between content of different culture variance in both content and property level, personally I'd rather be without.

[clausjensen]

@mathewknott the feature has so far been disabled on Cloud projects (in v7) so yes - that would be a perfectly viable solution for v8 as well. turns out it actually isn't disabled. It is just unsupported which means it is possible to use in some cases, but not a feature we support or encourage to use.

However as @kjac mentions - the code is not there for v8. It is a completely different scenario when we have to factor in variants, so the feature will have to be completely rethought and redone to actually support this in v8.

As the feature is something we would only be able to provide to a subset of our users, it does not currently have priority for HQ. We are of course always open to a community PR on this, but due to the amount of work required and the very likely possibility of having to do it all over due to considerations that don't come up initially... I cannot really recommend anyone to actually start working on this.

[AndyButland]

Do I have to hand my certificate back then (scroll to bottom)? :-)

[nul800sebastiaan]

@AndyButland It would definitely be something to consider re-instating that award for in the next year ;-)

As Claus mentioned, we won't put the work in right now, but we're open for incoming PRs!
I've marked this as "Up for grabs" so that you or someone else coming along could create a pull request for it.