U4-1491 - Trying to publish a root node (parent) after unpublishing a child result in a YSOD

Created by Martin Griffiths 17 Jan 2013, 14:31:02 Updated by Andy Dyton 27 Jun 2013, 10:19:18

Is duplicated by: U4-1587

Relates to: U4-2170

Relates to: U4-1577

Relates to: U4-1579

Depends on: U4-1577

Depends on: U4-1579

Depends on: U4-1582

Value cannot be null. Parameter name: attribute

=Please read this blog post for more information on how to upgrade and fix:= http://umbraco.com/follow-us/blog-archive/2013/2/1/umbraco-4114-released.aspx

6 Attachments

Download ContentPathFix.cs

Download report.txt

Download PathFixup_1.zip

Download report.zip


Matthias Daun 24 Jan 2013, 12:01:37

I experience the same exception, but it doesn't seem to be related to an unpublished child node. Are you able to publish the parent node via context menu: "Publish"? See: http://our.umbraco.org/forum/using/ui-questions/37750-4113-Publish-exception-Value-cannot-be-null

Martin Griffiths 25 Jan 2013, 10:06:05

Hi Matthias

I can confirm it publishes fine from the context menu so the YSOD is related only to the button!!

Very odd!

Niels Lynggaard 28 Jan 2013, 12:20:34

I have the same problem.. However, some nodes work ok.

Martin Griffiths 28 Jan 2013, 12:24:16

Hi Niels

I find the problem only happens on root nodes. All others publish fine.

I've also noticed that despite the YSOD the page actually still publishes.

Shannon Deminick 28 Jan 2013, 13:49:24

Do you have any custom indexes specified in your Examine config?

Matthias Daun 28 Jan 2013, 13:58:16

No, i haven't. Would it be helpful if i'd send a project copy to you? It's rather small at the moment.

Martin Griffiths 28 Jan 2013, 13:59:24

no I dont have any in my project either. Just out of the box settings

Niels Lynggaard 28 Jan 2013, 14:01:35


My setup is; Umbraco 4.11.3 Installed through WebMatrix, MSSQLExpress installed Packages; Ucomponents, famfamfam, Koiak Standard Site 1.1

Shannon Deminick 28 Jan 2013, 14:13:09

@Matthias, yeah might be helpful as I cannot seem to replicate this. Will keep trying though!

Matthias Daun 28 Jan 2013, 14:14:38

@Shannon: ok, what's your mail address?

Shannon Deminick 28 Jan 2013, 14:16:15


Shannon Deminick 28 Jan 2013, 14:26:43

@Niels, I've setup a site with those packages but still cannot replicate this error.

@All... unfortunately this error stems from UmbracoExamine while its trying to queue an item to be indexed. For whatever reason the XML that is going in to Examine is invalid. Theoretically this isn't an Examine related issue, it is an issue of the object being passed to Examine but without being able to replicate I'm not sure exactly where to fix this issue. We cannot fix this in the Examine codebase because it is an external DLL and we've already ported the UmbracoExamine source code into the 6.1 core. To make these changes to 6.0 is a ton of changes to the core and is much too late in the game to do that. The only other way I can think of to 'solve' this issue is to see if we can fix the object being passed to Examine (once I can replicate) or see if putting a try/catch around the event raising in Umbraco and catching the unhandled exceptions. Though this does not 'solve' the issue, it just masks it and causes another issue which is that the data will not get indexed by Examine.

Martin Griffiths 28 Jan 2013, 14:30:53

Hi Shannon

I would be quite surprised if this issue cannot be fixed within the Umbraco core because I DONT get a YSOD by using the context menu to publish. I only get a YSOD when I use the toolbar button.

Shannon Deminick 28 Jan 2013, 14:38:03

Well I'm nearly positive the exception happens in this method in the UmbracoExamine source:

public override void ReIndexNode(XElement node, string type) { if (!Enumerable.Contains(this.SupportedTypes, type)) return;

//THIS IS WHERE THE EXCEPTION OCCURS -> (int) node.Attribute((XName) "id") // IN THE STACK TRACE YOU CAN SEE THE REFERENCE TO THE op_Explicit WHICH IS // WHAT IS HAPPENING WITH THE (int) cast this.DataService.LogService.AddVerboseLog((int) node.Attribute((XName) "id"), string.Format("ReIndexNode with type: {0}", (object) type));

  base.ReIndexNode(node, type);

The above method accepts an XElement object which comes from the call:

UmbracoExamine.ContentExtensions.ToXDocument((Content) sender, true).Root

So somehow the ToXDocument method is creating invalid XML based on the 'Content' (sender) instance... So I would have to assume that it is the 'Content' object that is at fault since this normally works 99% of the time. ... now just need to replicate so I can see what the problem with the object actually is.

Niels Lynggaard 28 Jan 2013, 14:42:23

Its not a big issue for me, since its just the root node.

basically this error occured after unpublishing most nodes except a few ones and the root "site"-node.

Looking forward to 6.0 :)

Keep up the good work, Shannon!


Niels Lynggaard 28 Jan 2013, 17:51:27

Hmmm.. thats strange.. Now i get the same error on some of the sub-pages as well.. I tried deleting the xml cache I tried the republish through the /umbraco/dialogs/republish.aspx?xml=true

Hopefully Shannon will save us all in the next version of Umbraco :)

Gleb Kaplan 28 Jan 2013, 19:05:12

The same issue here after upgrading to v4.11.3 (Assembly version: 1.0.4760.34993), on production server only.

Shannon Deminick 28 Jan 2013, 20:55:17

Ok, I've finally got this replicating and have been able to get a break point set in the code. The problem is not Examine, it is the core. It turns out that it is not the 'root' node that is affected, it has to do with nodes being put into the recycle bin. When you publish a node this code executes:

foreach (var descendant in _document.GetDescendants().Cast().Where(descendant => descendant.HasPublishedVersion())) library.UpdateDocumentCache(descendant.Id);

It iterates over every descendant of the current document and fires the UpdateDocumentCache method which in turn fires the events which Examine listens to in order to index the content.

This issue is occurring because for some strange reason (a bug) the call to _document.GetDescendants() seems to sometimes (and not sure why yet) return a node that has been recycled, even though when I inspect this node in the watch window in VS, the node's parent ID is set to another node that is in the recycle bin. The other strange thing is that for this item in the recycle bin, the HasPublishedVersion() method also returns true.

The YSOD is then created because the UpdateDocumentCache fires for a node that is in the recycle bin and when Examine calls the method: UmbracoExamine.ContentExtensions.ToXDocument((Content) sender, true).Root it cannot find a published version and the XML returns is: "No published item exist with id 1156". Now of course Examine 'should' might want to check for this and not display a YSOD but it's probably best that it doesn't so we can find bugs in the core such as this... as it seems to be a bit of a nasty one.

So, now to track down this bug... which seems to be in two places:

  • _document.GetDescendants() -> should not return a node in the recycle bin, especially if that node's parent is of a completely different ID than that of _document.
  • HasPublishedVersion() -> should not return true if the item is in the recycle bin

This will be interesting to track down now since it doesn't seem to happen all of the time and I can't quite replicate this issue from scratch yet (only with @Matthias's code source sent to me... THX!!)

Niels Lynggaard 28 Jan 2013, 21:03:35

Good work, Shannon!

If its more help, I can also send you a copy of my site? It should be small, since its a fresh install I only started working on yesterday.

Shannon Deminick 28 Jan 2013, 21:19:13

I'm nearly positive that the fix is just due to HasPublishedVersion() but need to confirm with Sebastian and Morten. The current query for this does this check:

return (SqlHelper.ExecuteScalar("select Count(published) as tmp from cmsDocument where published = 1 And nodeId =" + Id) > 0);

BUT it needs to include the 'newest' field like:

return (SqlHelper.ExecuteScalar("select Count(published) as tmp from cmsDocument where published = 1 And newest = 1 And nodeId =" + Id) > 0);

That is if my assumption is correct and this method should only return true if the document is currently published not returning true if the document has ever been published in it's history.

Shannon Deminick 28 Jan 2013, 21:41:44

Definitely looks like there are 2 bugs here... the one I just mentioned with the HasPublishedVersion() (and changing this does fix this issue) but another issue remains and I've now figured out how to reproduce this issue.

Here's how to reproduce: Create structure: -> root --> Sub 1 ---> Child 1

Then delete 'Sub 1'. Then look in your database for the path of 'Sub 1'... you'll see that the path gets changed so that it's parent is "-20". But then look in your database for 'Child 1' you'll see that it's path remains exactly the same as it was and doesn't get modified. That means when you do a GetDescendants() from the 'root' it will include the 'Child 1' node but not 'Sub 1'

Shannon Deminick 28 Jan 2013, 23:56:54

So this was caused by a few issues but ultimately caused by a change in revision: 8de243afb77d which added some optimization logic but unfortunately broke a few things, the biggest one being: http://issues.umbraco.org/issue/U4-1579

I've updated this issue with all dependent issues which are now all resolved. U4-1579 is a critical issue and if you have been running 4.10+ then you'll absolutely 100% want to update to this new version because all of your paths for any descendant nodes of any nodes that you've 'moved' will all be incorrect. This will cause things like umbraco.cms.businesslogic.web.Document.GetDescendants() to return invalid results (among other issues like this one)

Shannon Deminick 29 Jan 2013, 00:04:46

So, we still have an issue with this however. Even though these other fixes fix the underlying cause of the problem, the problem still remains if you have it currently and that is because the paths for nodes in the recycle bin that exist at a level deeper than 1 will be incorrect and will still reference ancestors in the main tree (not in the recycle bin).

The only way I can think to fix this is by a script, so I'll write one up that you can (hopefully) just drop into the App_Code folder and it will fix all paths in the database on application startup. I'll post it up here when I'm done.

Shannon Deminick 29 Jan 2013, 01:42:12

Here's the script to fix-up the database issues, it will fix up all Paths and Level's for all content and media nodes. This script should be run for any installation 4.10+ since you will have database inconsistencies if you have moved or deleted nodes (which I'd assume most people have)

Put this script directly into your App_Code folder and it will execute probably as soon as you go to any page on your website. It will generate a report at ~/App_Data/TEMP/FixPaths/report.txt for all of the things it has changed. You'll see an "INVALID PATH DETECTED..." message for all of the ones it found were incorrect and fixed. This script will probably be quite CPU intensive and will only be executed once (based on whether or not the report.txt exist). Once you run it, it is advised to remove this file from App_Code.

Now to figure out a good way to execute scripts on upgrades that aren't just SQL.

Shannon Deminick 29 Jan 2013, 01:55:31

OH... THIS IS IMPORTANT!!!... I should mention you should create a backup of your db before running that script (just in case :)

Rasmus Fjord 29 Jan 2013, 08:25:45

Hey Shannon just read all the lines here. Think i had the same issue, it sould like you have figured out where the issues was. For me it helped to empty the recycle bin for some reason. My issues happend after upgrading from 4.11 to

Niels Lynggaard 29 Jan 2013, 09:08:06

Shannon you rock. Don't you sleep once in a while?! #h5yr

Martin Griffiths 29 Jan 2013, 09:44:39

Hi Shannon

What will I need to upgrade umbraco or do I just run the script?


Niels Lynggaard 29 Jan 2013, 10:13:32

I tried your solution, Shannon, the script runs and generates a report, but it doesn't fix the YSOD when publishing the nodes that I know was broke before.

Matthias Daun 29 Jan 2013, 11:10:55

@Martin, @Niels: if i understand it right, you will need to upgrade to 4.11.4, but it seems there isn't an actual build yet: http://nightly.umbraco.org/umbraco%204.11.4

Martin Griffiths 29 Jan 2013, 11:14:45

Hi Matthias

I cant get into the habit of using nightlies for my project work, it's just asking for trouble. I'll just have to wait for the next release. Hopefully it wont be too long to wait.


Jon Carlos 29 Jan 2013, 11:39:13

When i ran the script Shannon provided to fix the issue I recieved a "No Document exists with Version '00000000-0000-0000-0000-000000000000'" error.

It seems my database had some orphaned nodes and while I could not find the document with that GUID there were notes that were not in the cmsContent table.

To fix I Ran: SELECT * FROM umbracoNode, cmsContent -- return nodes WHERE nodeObjectType = 'C66BA18E-EAF3-4CFF-8A22-41B16D66A972' -- that are of type 'Content' AND umbracoNode.id NOT IN (SELECT nodeId FROM cmsContent) -- but are not in the 'Content' table

to Identify the node that were causing the problem followed by: DELETE FROM [umbracoNode] where uniqueID = 'PUT THE GUIDS LISTED FROM THE PREVIOUS CALL IN HERE'

Notes: Backup you database this deletes records!

Jon Carlos 29 Jan 2013, 12:02:25

Once I had run the script Shannon provided I'm still experiencing the same issue.

I have also updated the DLL's to the latest version from nightly build but the issue is still there.

Any ideas? I don't experience this issue on leaf nodes and most leaf parents are ok too but on parent, parent the issues raises it's head.

I cleared the Recycle Bin but thats not fixed the issue either

Shannon Deminick 29 Jan 2013, 14:41:27

Hrm.. Ok so I found this issue based on the db that @Matthias provided me and I ran the fix against his installation and it all worked well (can you please confirm this @Matthias?). Now I'm not sure how to fix the rest of your issues without obtaining a copy of your installation + db so I can debug it. Anyone willing to send me your site?

Niels Lynggaard 29 Jan 2013, 14:56:23

Sure, I'll wrap mine up for you, its a tiny installation..

Matthias Daun 29 Jan 2013, 14:59:34

@Shannon: yes, worked for me and i can't reproduce the issue anymore.

Martin Griffiths 29 Jan 2013, 15:03:00

I wish I could but it's nearly ready for production and has client data in it now! Dang! So are we talking a script to fix this or a new build?

Shannon Deminick 29 Jan 2013, 15:05:55

@Martin: It will require both. Any install from 4.10+ will have issues any time you move a content item (or recycle it which is the same thing). If you do that the descendants of the node that you have moved will not have their paths/level/trashed flag updated properly. The latest 4.11.4 build has this fixed but if you already have errors in your database then you will also require a script to fix it.

Shannon Deminick 29 Jan 2013, 16:08:50

Have found another database issue with @Niels's install and hopefully this is probably what you are all experiencing (see attached file)... At the moment I'm not sure how a node can become this way. I would assume that when a node is unpublished that all of it's descendant nodes have their 'published' flag set to 0 as well. I'll have to run some tests to see if this is or isn't the case. It must have been the case in prior version of Umbraco otherwise we would have seen this issue a very long time ago.

Jon Carlos 29 Jan 2013, 16:55:06

Hi Shannon

You're assumption is incorrect, certainly in 4.7 and probably in later versions if nothing has changed there.

I have often found when you have a section published and unpublish the root of that section non of the children are unpublished or removed from the XML and if you know the URL you can still navigate to the sub pages even though the parent is unpublished.

It's totally possible that my site also has the same issue as in your diagram. If you need the DB and site let me know and I'll get it online for you to have a look at.

Jon Carlos 29 Jan 2013, 17:02:59

Hi Shannon

I have just worked through the site I'm having the problem with and published all the nodes that were unpublished but had children "This document is published but is not visible because the parent 'PARENT NODE NAME' is unpublished" and published then unpublished all the children the unpublished the parent node again and it's resolved the issue.

Looks like the malformed XML may be due to a missing/unpublished parent for children that are published.

Hope this helps

Shannon Deminick 29 Jan 2013, 17:08:48

I've found the issue guys, stay tuned for the fix today. Unfortunately this fix is a core change so a script will not temporarily fix this one for you. However I will be able to tell you how to manually fix this if you don't want to upgrade... but manually fixing it will only temporarily solve it. Give me a couple hours and I'll post up the final status.

Martin Griffiths 29 Jan 2013, 17:13:03

Awesome Shannon, Look forward to the fix. How can I best message you regarding MVC stuff?

Shannon Deminick 29 Jan 2013, 17:15:36

If you have a question, etc.. .and it is not on Our then please post there and ping me the link on twitter. That way everyone can benefit from the answer. Otherwise if it's to do with the core then please post on mail list. Otherwise if it is a bug, please post here :)

Jon Carlos 29 Jan 2013, 17:16:01

Great Shannon, Cheers for the attention to this.

Shannon Deminick 29 Jan 2013, 23:16:47

Ok guys, have finally fixed this and a bunch of other issues relating. It took a while to figure out what was going on but I got there in the end...lets begin :)

There's actually 2 things that do the same thing in the Document class: the Published property and the HasPublishedVersion() method. These are the same so I've obsoleted HasPublishedVersion() since the Published property is nicer. This will return true if the document has a published version in the database regardless of whether it is published on the front-end. I've also modified the Published property to lazy load the value which will improve performance. http://issues.umbraco.org/issue/U4-1595

Next up is the PathPublished property on Document. This will return true if the document is published on the front-end, meaning that it and all of its ancestors are published. I've modified this as well to make it lazy loaded and cached in the instance to improve performance. http://issues.umbraco.org/issue/U4-1597

Next up, the content tree needs to check for PathPublished not just published, was a slight fluke that the css worked to dim the nodes correctly. http://issues.umbraco.org/issue/U4-1593

next was to change the codebase to not use the new obsoleted calls and create a new method on document called GetPathPublishedDescendants() so that we are not making n+1 SQL calls in the editContent page... this will improve performance dramatically when publishing, etc... http://issues.umbraco.org/issue/U4-1596

This method will only return descendants that have their full path's published which is used in editContent to refresh the front-end cache and thus solving THIS bug: http://issues.umbraco.org/issue/U4-1491

And this will all dramatically improve SQL performance... pretty sure this could save on TONs of queries, especially if you have many descendant nodes.

So, how to fix your install? Well, in some cases you will need to run the script that I posted here, but we are going to have that as part of the install/upgrade process for the 4.11.4 release. This will fix issues with moving/paths. Next, you'll need to use the latest codebase in 4.11.4, if you want to get started with the nightlies that is cool too.

Shannon Deminick 30 Jan 2013, 02:02:03

Ok dudes, if you can all test 4.11.4 (if you can) at revision at least: f2a8b3b1da44

This should fix all your issues (but also run the script I attached before too)

If you guys do test it would be much appreciated if you can report if you actually see any difference in performance too. There's should be a TON less SQL calls being made, though it might not be too noticeable on small sites, not sure.

esunxray 30 Jan 2013, 02:38:44

Thank you. I'd like to test it if I have time.

Kenneth 30 Jan 2013, 07:16:10

Good job! When will 4.11.4 be released?

Niels Lynggaard 30 Jan 2013, 07:22:07

I'll give it a go later today. Thanx, Shannon.

Matthias Daun 30 Jan 2013, 07:24:55

Thanks Shannon, great job! #h5yr! Will test it later today.

Martin Griffiths 30 Jan 2013, 08:56:28

Wow Shannon, looks like you've really nailed it and uncovered (and fixed) many other issues as a consequence. Top marks to you sir!

I would get lynched if I used nightlies in our production environment. Any ideas how long 4.11.4 is from release?


Shannon Deminick 31 Jan 2013, 16:27:56

It has been discussed in the HQ that the path fix script will be released as a package (dashboard control), so have re-opened this issue until that is complete.

Niels Lynggaard 31 Jan 2013, 18:35:17

Sounds reasonable. I didn't test yesterday, would you like me to test that build of 4.11.4? I can test on that website I sent you.

Christian Iversen 31 Jan 2013, 19:05:28

How can I download 4.11.4 before it is released? Can you get a zip of a specific revision somehow?

Niels Lynggaard 31 Jan 2013, 22:22:59

  1. 6.0.0 is out today, maybe give that a spinn? ;)

Shannon Deminick 31 Jan 2013, 23:00:57

You can download nightly builds from our server of any release here: http://nightly.umbraco.org/

Shannon Deminick 31 Jan 2013, 23:12:50

Here's a package I've created today to run this fix instead of having the script run automatically in the App_Code folder. We'll release this on Our today I think too. It should be used if you have this issue... HOWEVER you might still get this issue if you are running on a version less than 4.11.4 and that is because of this (which you can solve manually in your instance if you are not going to upgrade):

If you have this structure:

-> Home --> Page 1 ---> Sub Page 1 ---> Sub Page 2

and they are all published, and then you un-publish "Page 1". You will get this YSOD listed here if you try to publish "Home".

This is because in the core it is trying to refresh the published cache (XML) for all descendants that are published and since "Sub Page 1" and "Sub Page 2" have a published flag in the database it will try to update the published cache for these 2 nodes even though these 2 nodes are not published on the front-end (because their parent is un-published). This is why this YSOD is generated in some cases if the script/package that I've uploaded doesn't solve your problem.

So, to manually fix this issue (if you aren't going to upgrade or need it fixed asap) is to go find pages that are published but one of their ancestors is unpublished and then manually un-publish those too. For example with the structure listed here, we'd have to go un-publish "Sub Page 1" and "Sub Page 2".

You can tell if a page is published but is not visible on the front-end because the 'Link to document' will read "This document is published but is not visible because the parent 'Sub 1' is unpublished"

Shannon Deminick 01 Feb 2013, 00:32:14


Martin Griffiths 01 Feb 2013, 09:52:59

Has these bugfixes all made their way into v6?

Sebastiaan Janssen 01 Feb 2013, 10:33:26

@Martin yes, the bugs have been fixed in 4.11.4 and 6.0.0. Read more: http://umbraco.com/follow-us/blog-archive/2013/2/1/umbraco-4114-released.aspx

Merijn van Mourik 01 Feb 2013, 15:19:21

Hmm when installing the path-fixup, the following occurs (4.11.4)

Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

Sebastiaan Janssen 01 Feb 2013, 15:42:40

@Merijn sorry about that, it was just updated to support .net 4.0 (was compiled against 4.5 before), please re-download and try again.

Paul Wright 06 Feb 2013, 12:53:31

I ran the path-fixup, which worked perfectly.

However, the examine index was still holding the old (wonky) paths. I re-built the examine index as a final step and all was hunky dory.

Shannon Deminick 06 Feb 2013, 12:56:51

Doh! I wonder why that is, Examine should fire on the events when saving stuff during the script. I can have a look. Thanks for the heads up

Paul Wright 06 Feb 2013, 13:04:06

Ahh - might because it was a custom index set (used on the front end of the site for 'site search'), rather than the backoffice indexset. I assume path-fixup just rebuilds "InternalIndexSet"

Shannon Deminick 06 Feb 2013, 13:09:41

If it's an index set based on Umbraco data then it should be listening to Umbraco events to index the data, unless you have a very custom index that indexes data based on your own events?

Simon Dingley 25 Feb 2013, 14:40:30

What do we do when encountering this message which causes the FixUp process to stop?

INVALID PATH DETECTED. Path for 2130 changed to: -1,1721,1723,2480,2415,2130

Shannon Deminick 25 Feb 2013, 14:44:34

@Simon, are you using the latest version ? We have added logging to the project now so depending on the version of Umbraco you are running the logs will go either in the log4net file or in the umbracoLog table.

Simon Dingley 25 Feb 2013, 14:48:38

Ah ok perhaps I'm not running the latest Path Fixup, in case you were referring to Umbraco it's 4.11.4. Will grab another copy to ensure I'm running the latest tool - thanks.

Mikkel Mikkelsen 09 Apr 2013, 13:51:47

I ran the path fix, and it while it did fix a couple issues, I also got a ton of errors like the following:

2013-04-09 15:45:50.196 - An error occurred looking up document 35907. Exception details: System.ArgumentException: No Document exists with Version '00000000-0000-0000-0000-000000000000' at umbraco.cms.businesslogic.web.Document.setupNode() at umbraco.cms.businesslogic.CMSNode..ctor(Int32 Id) at UmbracoPathFix.ContentPathFix.Fix() in c:\Users\shannon\Documents~Jobs\UmbracoPathFix\UmbracoPathFix\ContentPathFix.cs:line 62

I can post the full report.txt if you need it, but it's mostly exactly the same error as above. Running version 4.11.4

Gleb Kaplan 09 Apr 2013, 17:05:41

The error just started to re-appear again during publishing. Umbraco 4.11.5. I tried to re-run FixPath, emptied recycling bin, re-published all content, rebuilt Examine indexes - unfortunately all this did not help. The report.txt is attached. Please advise.

2013-04-09 17:57:06,112 [5] ERROR Umbraco.Web.UmbracoApplication - [Thread 15] An unhandled exception occurred System.Web.HttpUnhandledException (0x80004005): Exception of type 'System.Web.HttpUnhandledException' was thrown. ---> System.ArgumentNullException: Value cannot be null. Parameter name: attribute at System.Xml.Linq.XAttribute.op_Explicit(XAttribute attribute)

P.S. Republishing the grandfather node (with all children) resolved the issue (this time...)

Jan Skovgaard 15 Apr 2013, 08:24:36

@Shannon: Seeing the same issue as Mikkel after doing an upgrade from 4.11.1 to 4.11.6. More specifically I see this: 2013-04-15 10:16:18.822 - An error occurred publishing the document 1716. Exception details: System.InvalidCastException: Unable to cast object of type 'System.Web.Mvc.MvcHandler' to type 'umbraco.BasePages.BasePage'. at DFFEDB.Backend.AdminSaveHandlers.Document_AfterPublish(Document sender, PublishEventArgs e) in D:\data\HG\DFFEDB-Varmevaerksider\DFFEDB.Backend\AdminSaveHandlers.cs:line 29 at umbraco.cms.businesslogic.web.Document.PublishEventHandler.Invoke(Document sender, PublishEventArgs e) at umbraco.cms.businesslogic.web.Document.PublishWithResult(User u) at UmbracoPathFix.ContentPathFix.FixPath(CMSNode d) in c:\Users\shannon\Documents~Jobs\UmbracoPathFix\UmbracoPathFix\ContentPathFix.cs:line 187

Not sure if it's something I should worry about?

Mikkel Mikkelsen 15 Apr 2013, 08:34:03

@Jan: I managed to fix my issue by temporarily disabling the foreign key FK_umbracoNode_umbracoNode on the umbracoNode table, running the following query (deletes nodes from the recycle bin):

-- Uncomment below to verify the number of nodes returned is the -- same as the number of nodes that is in the Recycle Bin -- select * from umbracoNode where path like '%-20%' and id!=-20 -- Delete all 'related' nodes and table contents... delete from cmsPreviewXml where nodeId in (select id from umbracoNode where path like '%-20%' and id!=-20) delete from cmsContentVersion where contentId in (select id from umbracoNode where path like '%-20%' and id!=-20) delete from cmsDocument where nodeId in (select id from umbracoNode where path like '%-20%' and id!=-20) delete from cmsContentXML where nodeId in (select id from umbracoNode where path like '%-20%' and id!=-20) delete from cmsContent where nodeId in (select id from umbracoNode where path like '%-20%' and id!=-20) delete from cmsPropertyData where contentNodeId in (select id from umbracoNode where path like '%-20%' and id!=-20) -- delete the XML nodes.... delete from umbracoNode where path like '%-20%' and id!=-20 .. and then finally going into the umbraco backoffice to manually empty the recycle bin, then re-enabling the foreign key. Not sure if it will help you, but it might be worth a shot

Shannon Deminick 15 Apr 2013, 15:47:19

@Jan, your issue seems to be your code or 3rd party code. Your stack trace shows the exception happening here:

at DFFEDB.Backend.AdminSaveHandlers.Document_AfterPublish(Document sender, PublishEventArgs e) in D:\data\HG\DFFEDB-Varmevaerksider\DFFEDB.Backend\AdminSaveHandlers.cs:line 29

which is outside of Umbraco.

Arie 05 Jun 2013, 19:55:10

I encountered this problem (or a very similar problem) in 6.0.5. However, this site started as a 6.x.x site - never was on 4.x.x.

The good news is that Shannon's script (Path Fixup) resolved the problem, but apparently the core problem has not yet been resolved (in 6.0.5).

Shannon Deminick 05 Jun 2013, 21:44:35

@Arie, we did fix the core problem so I'm now wondering if there is another edge case problem as there would have been many other people reporting this issue. I'll need a full stack trace of your issue and if you have any knowledge of how to reproduce.

Sebastiaan Janssen 06 Jun 2013, 12:22:38

@Arie please create a new issue for this when you have a stack trace. Thanks.

Andy Dyton 27 Jun 2013, 10:19:18

I also encountered this problem as a result of an upgrade from 4.7 to 4.11 to 6.1.1.

It seems the path fix-up package didn't resolve the issue in isolation, but emptying the recycle bins, re-running the path fix-up package and then republishing appears to have done the trick.

I'll continue to monitor the situation, but if anyone's experiencing a similar problem I'd recommend clearing out the recycle bin, as this appears to be part of the problem.

Priority: Critical

Type: Bug

State: Fixed

Assignee: Shannon Deminick

Difficulty: Normal


Backwards Compatible: False

Fix Submitted:

Affected versions: 4.10.0, 4.11.0, 4.11.1, 4.11.2, 4.11.3, 6.0.5

Due in version: 4.11.4


Story Points: