U4-5931 - DocType Inheritance Issue

Created by Tom Steer 03 Dec 2014, 15:49:36 Updated by Robert Lewis 04 Jun 2015, 19:19:24

There seems to be an issue with multi level doctype inheritance by where 2nd (possibly deeper as well) level doctypes aren't getting the properties from the top level doctype.

I've attached a screenshot of an example, you will notice that the Home node doesn't have the SEO tab yet it is present on the Base doctype.

6 Attachments

Download Base.udt

Download Home.udt

Download Menu.udt

Download 7.20-U4-5931-fix.zip


Sebastiaan Janssen 03 Dec 2014, 16:02:35

Are you using compositions for this? Please note that in the final version of 7.2 the compositions option will be more strict in what you can and cannot compose together. This is to prevent circular dependencies from happening which is too easy in the RC version. You might not be able to build the doctype structure that you're building now in the final version of 7.2.

Tom Steer 03 Dec 2014, 16:05:52

No this isn't using any compositions, it was originally but then i changed it back to just using inheritance as you can see from the screenshot attachments.

Sebastiaan Janssen 03 Dec 2014, 16:07:13

Could you do me a favor and export Base (just right-click it and export) and attach it here so I can have a look?

Tom Steer 03 Dec 2014, 16:13:33

Just attached it :)

Sebastiaan Janssen 03 Dec 2014, 16:17:00

Ah, I was hoping that would also include menu and home but it didn't, could you export those as well please? :)

Tom Steer 04 Dec 2014, 15:49:00

Sorry Seb had a bit of a hectic day with servers today. Here are the exports for Menu & Home.

Nicholas Westby 05 Dec 2014, 17:22:31

Seems others are experiencing this too: http://our.umbraco.org/forum/umbraco-7/using-umbraco-7/59555-Umbracpo-v72-Doc-Types-lose-inherited-properties

Stephan 09 Dec 2014, 13:48:54

From the tree we see that Base is the parent of Menu and Menu is the parent of Home. Yet looking at the UDT files, we see that Home is composed of Menu, but Menu is not composed of anything. This is not normal, as a data type should always at least be composed of its own parent.

There was a possibility in 7.2.0 pre-RTM releases (betas & RC) to remove the parent from the compositions, but that should not be possible anymore with the RTM version.

Can you confirm that you obtained this situation with pre-RTM releases?

Now, on how to fix it... it it tricky because the UI will not let you check/uncheck the parent in the compositions list. Best (prob. only) way to just fix (as opposed to re-create everything) would be by adding a row in the DB - let me know if you want instructions.

Stephan 09 Dec 2014, 16:04:43

Confirmed: create Type1 > Type2 > Type3 and then save Type2, it looses the Type1 composition though Type1 remains the parent. Working on it.

Stephan 09 Dec 2014, 17:00:04

Committed 9dcba6a67929aca0dc4a60c33275e3da25b266f6 to 7.2.1 - should fix the issue.

Sebastiaan Janssen 09 Dec 2014, 17:16:02

Just as an FYI: There is a manual way to fix this in 7.2.0 and that is to go into the cmsContentType2ContentType table and add the parent/child combinations back that are missing. However, if you then save a document type in the interface this problem will occur again so you'd need to fix it in the database again.

Testing the fix now.

Sebastiaan Janssen 09 Dec 2014, 17:47:12

This seems to work now. For people to whom this already happened, you will have to recreate the links between document types in the database. If you copy in the attached umbraco.dll then you can safely update your doctypes from the interface until we release 7.2.1.

So this is the exact same umbraco.dll that shipped with 7.2.0 final with the fix for this issue applied, no other changes, just the fix for this issue.

Peter Gregory 10 Dec 2014, 01:27:21

This happened to me this morning. However after relinking the document types all the data that was recorded for the document type against the parent is all gone :( The hotfix returns the property fields but none of the data as I suspect Umbraco was helpful and saw that the document type no longer had the property so no longer needs the data so dropped all that :(

Going back to a DB backup to try and recover the property data for the lost fields.

Peter Gregory 10 Dec 2014, 03:02:16

One other thing. After re-establishing the connection and putting your properties back the Cache doesnt update. Im fighting through this one at the moment will report how I fixed it once I have it fixed up.

Peter Gregory 10 Dec 2014, 03:56:27

Ok it does update the one on disk but not in memory. Had to touch the web.config to get it bring back the cache.

Peter Gregory 10 Dec 2014, 08:17:05

Back to normal again with 300 pages of screwed up content restored. It may help others train of thought when trying to fix it so thought I would add my process here. The process to get back on track required some real messing around.

  1. Applied Sebs Fixes (both patch and DB fix) as mentioned above.
  2. Restored an old backup of the site and DB that still had the data in our case even a day is a big deal. So much changes both in membership and content that just doing a complete restore over the top of the live site was not possible.
  3. Exported all the missing data as a CSV (Razor script)
  4. Imported CSV updating all the F'd up nodes and republishing them.

Janne Mårtensgård 10 Dec 2014, 08:27:40

This bug bit us too this morning. No major harm done (it only affected a few pages so reentering the data was trivial) but it really should be brought up on the blog and in a mail together with the hotfix as it could potentially mean huge data losses for people.

Sebastiaan Janssen 10 Dec 2014, 08:33:06

A fix, plus fix for U4-5986 is going out today.

Robert Lewis 04 Jun 2015, 19:19:24

What happens if my client doesn't have a backup of the database and all they SEO etc has gone?

Priority: Normal

Type: Bug

State: Fixed

Assignee: Stephan

Difficulty: Normal


Backwards Compatible: True

Fix Submitted:

Affected versions: 7.2.0

Due in version: 7.2.1


Story Points: