Duplicate node after upgrading to v6.1.5 from v4.11
One of my nodes in the content tree appears twice with the same node id.
I had previously had that problem if that node happened to have two default templates in the db, but this isn't the case this time. There appears to be absolutely no reason why it would appear twice.
What's also bizarre is that the name of that tree node seems to copy itself with every postback. So if the name is called "node.123" it starts rendering as "node.123.node.123.node.123.node.123.node.123..." and and it also appears twice.
This problem with the name happens only on this node that is duplicate.
Any ideas what could be messing it up? I have uComponents installed and I read somewhere that uComponents could mess up the tree but I am not sure how to confirm.
Well.. not sure if it's something that somehow happened to my database or something that can also happens to others.
The problem is that this internal umbraco query :
SELECT umbracoNode.id, umbracoNode.trashed, umbracoNode.parentID, umbracoNode.nodeUser, umbracoNode.level, umbracoNode.path, umbracoNode.sortOrder, umbracoNode.uniqueID, umbracoNode.text, umbracoNode.nodeObjectType, umbracoNode.createDate, COUNT(parent.parentID) as children, published.versionId as publishedVerison, latest.versionId as newestVersion, contenttype.alias, contenttype.icon, contenttype.thumbnail FROM umbracoNode umbracoNode LEFT JOIN umbracoNode parent ON parent.parentID = umbracoNode.id INNER JOIN cmsContent content ON content.nodeId = umbracoNode.id LEFT JOIN cmsContentType contenttype ON contenttype.nodeId = content.contentType LEFT JOIN (SELECT nodeId, versionId FROM cmsDocument WHERE published = 1 GROUP BY nodeId, versionId) as published ON umbracoNode.id = published.nodeId LEFT JOIN (SELECT nodeId, versionId FROM cmsDocument WHERE newest = 1 GROUP BY nodeId, versionId) as latest ON umbracoNode.id = latest.nodeId WHERE (umbracoNode.nodeObjectType = '@parameter) AND (`umbracoNode`.`parentID` = -1) GROUP BY umbracoNode.id, umbracoNode.trashed, umbracoNode.parentID, umbracoNode.nodeUser, umbracoNode.level, umbracoNode.path, umbracoNode.sortOrder, umbracoNode.uniqueID, umbracoNode.text, umbracoNode.nodeObjectType, umbracoNode.createDate, published.versionId, latest.versionId, contenttype.alias, contenttype.icon, contenttype.thumbnail ORDER BY umbracoNode.sortOrder
ORDER BY umbracoNode.sortOrder
returns duplicate nodes.
This is because SELECT nodeId, versionId FROM cmsDocument WHERE published = 1 GROUP BY nodeId, versionId) as published
Returns two records with the same nodeId that appear to be published with different versions.
By unchecking the "published" flag from the one that isn't mark as newest the duplicate disappears.
I think this query should be updated to take care of that and only select the newest one.
Looking at it, seems like somehow the upgrade made it so there were '2' published nodes, which in theory should never happen, hence the first query not checking for this.
Does anyone here have a solution to the problem? I've just done an upgrade from v4.11.10 > v6.2.1 and have a customer with the same issues in both the content tree and the media trees.
I have just carried out an upgrade from v4.11.5 to v6.2.4 and now have the same issue where some (but not all) of the content items are duplicated in the content tree and have the same nodeIds. The Media tree looks fine though.
We think we've corrected out issue - running the SQL provided in Nick's other post here returned all our duplicate nodes. We did have Contour installed but have since uninstalled it and moved to a simpler server model.
I'm not sure if Courier is the issue here, but it looks like there are two published versions of the node; one of that isn't the newest and the Content tree is rendering both. When we tried sorting the Content tree, no duplicates showed up.
We backed up our database and ran the following script to update the records:
UPDATE dbo.cmsDocument SET published = 0 WHERE nodeId IN (SELECT nodeId FROM cmsdocument WHERE published = 1 GROUP BY nodeId, published HAVING COUNT(published) > 1) AND published = 1 AND newest = 0
Following this, we republished the entire site and the issue was gone :-)
In the meantime, I had tried upgrading from v4.11.5 to v6.0.7 and the issue did not appear; it was only when I upgraded to 6.1.1 or above, so it looks like the way the Content tree is retrieved/built changed in 6.1.0 / 6.1.1 and above.
Sorry for the late reply. This issue resolved itself in time so I think it was some sort of post upgrade caching problem. Whilst visibly the nodes were duplicated all duplicates shared the same node id's so they weren't true duplicates. This is something I was quick to point out to the customer when they started deleting duplicate nodes only to find both disappeared!
Duplicate node after upgrading to v6.1.5 from v4.11
One of my nodes in the content tree appears twice with the same node id.
I had previously had that problem if that node happened to have two default templates in the db, but this isn't the case this time. There appears to be absolutely no reason why it would appear twice.
What's also bizarre is that the name of that tree node seems to copy itself with every postback.
So if the name is called "node.123" it starts rendering as "node.123.node.123.node.123.node.123.node.123..." and and it also appears twice.
This problem with the name happens only on this node that is duplicate.
Any ideas what could be messing it up?
I have uComponents installed and I read somewhere that uComponents could mess up the tree but I am not sure how to confirm.
Any help is very appreciated
I managed to run the source of umbraco and found out the problem.
It's a buggy internal umbraco query
Is it something that you can replicate? If so please report it so it can be fixed!
Well.. not sure if it's something that somehow happened to my database or something that can also happens to others.
The problem is that this internal umbraco query :
SELECT umbracoNode.id, umbracoNode.trashed, umbracoNode.parentID, umbracoNode.nodeUser, umbracoNode.level, umbracoNode.path, umbracoNode.sortOrder, umbracoNode.uniqueID, umbracoNode.text, umbracoNode.nodeObjectType, umbracoNode.createDate, COUNT(parent.parentID) as children, published.versionId as publishedVerison, latest.versionId as newestVersion, contenttype.alias, contenttype.icon, contenttype.thumbnail FROM umbracoNode umbracoNode LEFT JOIN umbracoNode parent ON parent.parentID = umbracoNode.id INNER JOIN cmsContent content ON content.nodeId = umbracoNode.id LEFT JOIN cmsContentType contenttype ON contenttype.nodeId = content.contentType LEFT JOIN (SELECT nodeId, versionId FROM cmsDocument WHERE published = 1 GROUP BY nodeId, versionId) as published ON umbracoNode.id = published.nodeId LEFT JOIN (SELECT nodeId, versionId FROM cmsDocument WHERE newest = 1 GROUP BY nodeId, versionId) as latest ON umbracoNode.id = latest.nodeId WHERE (umbracoNode.nodeObjectType = '@parameter) AND (`umbracoNode`.`parentID` = -1) GROUP BY umbracoNode.id, umbracoNode.trashed, umbracoNode.parentID, umbracoNode.nodeUser, umbracoNode.level, umbracoNode.path, umbracoNode.sortOrder, umbracoNode.uniqueID, umbracoNode.text, umbracoNode.nodeObjectType, umbracoNode.createDate, published.versionId, latest.versionId, contenttype.alias, contenttype.icon, contenttype.thumbnail ORDER BY umbracoNode.sortOrder
ORDER BY umbracoNode.sortOrder
returns duplicate nodes.
This is because
SELECT nodeId, versionId FROM cmsDocument WHERE published = 1 GROUP BY nodeId, versionId) as published
Returns two records with the same nodeId that appear to be published with different versions.
By unchecking the "published" flag from the one that isn't mark as newest the duplicate disappears.
I think this query should be updated to take care of that and only select the newest one.
Nice one for posting.
Looking at it, seems like somehow the upgrade made it so there were '2' published nodes, which in theory should never happen, hence the first query not checking for this.
I have same problem with update from 4 - duplicate folders in Umbraco content tree, same node ids
Does anyone here have a solution to the problem? I've just done an upgrade from v4.11.10 > v6.2.1 and have a customer with the same issues in both the content tree and the media trees.
Simon
Hi,
I have just carried out an upgrade from v4.11.5 to v6.2.4 and now have the same issue where some (but not all) of the content items are duplicated in the content tree and have the same nodeIds. The Media tree looks fine though.
Is there any update on this please?
Thanks,
James.
Hi all,
We think we've corrected out issue - running the SQL provided in Nick's other post here returned all our duplicate nodes. We did have Contour installed but have since uninstalled it and moved to a simpler server model.
I'm not sure if Courier is the issue here, but it looks like there are two published versions of the node; one of that isn't the newest and the Content tree is rendering both. When we tried sorting the Content tree, no duplicates showed up.
We backed up our database and ran the following script to update the records:
Following this, we republished the entire site and the issue was gone :-)
In the meantime, I had tried upgrading from v4.11.5 to v6.0.7 and the issue did not appear; it was only when I upgraded to 6.1.1 or above, so it looks like the way the Content tree is retrieved/built changed in 6.1.0 / 6.1.1 and above.
Hope that helps!
James.
Sorry for the late reply. This issue resolved itself in time so I think it was some sort of post upgrade caching problem. Whilst visibly the nodes were duplicated all duplicates shared the same node id's so they weren't true duplicates. This is something I was quick to point out to the customer when they started deleting duplicate nodes only to find both disappeared!
is working on a reply...