Umbraco-cms: 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 [e-mail] 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
https://github.com/umbraco/Umbraco-CMS/issues/5070#issuecomment-478558097,
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.

[nul800sebastiaan]

This issue has been in the up for grabs state for quite a while now and it seems nobody is ready to pick this one up.

For now we'll close this issue to prevent the list of up for grabs from becoming very stale. We're happy to re-open it if someone still thinks it's good to work on this.

If anyone is about to pick this issue up to fix it, make sure to test first if you can reproduce the problem in the latest version before you start to work on it.

Thanks!
Sebastiaan on behalf of Umbraco HQ.

[snerpton]

Hi @nul800sebastiaan,

One aspect of Umbraco that has been particularly useful as a developer is its agility, the ability to find a good solution for a business requirement, and then iterate at some point in the future. An important part of the agility of Umbraco 7 was the ability to change document type.

Without the ability to change document type, I believe the alternative is to recreate content as the new document type, but this can be a huge undertaking on some of the sites we host (e.g. large UK PLC and NHS hospitals) where recreating many 100s of pages of content just isn't practical.

Are there any other ways to achieve this?

I appreciate implementing the ability to change document type is difficult, and may not be top of the priority list, but I'm keen this important (for us) functionality doesn't drop off HQ's radar.

Is keeping this ticket open the best place to do this, or can I log this feature request elsewhere?

[nul800sebastiaan]

Thanks @snerpton (sorry, I missed your reply in September) - currently HQ has no plans for working on this feature. It's still set to "Up For Grabs" but nobody has "grabbed" it for a long time. and there's no reason to believe someone will, given the complexities involved. Hence it being closed (but still searchable through the "Up For Grabs" label).

Personally, I would love to see a feature like this again, but it might be better make a more general "refactor" dashboard in the settings section. In there, you would have plenty of room to map properties and get a good overview of how (and if) variants can be mapped to each other.