I just installed Blog4Umbraco, I'm using umbraco 4.0.3 in Firefox, and I tried creating a second blog. On the second blog, when I create a Blog Post by right clicking on the 2nd blog and selecting Create, then after I publish and reload the tree, each node is listed twice in the content tree even though they all reference the same node. It looks like:
Blog2 -2010 --5 ---4 ----Blog post ---4 ----Blog post --5 ---4 ----Blog post ---4 ----Blog post -2010 --5 ---4 ----Blog post ---4 ----Blog post --5 ---4 ----Blog post ---4 ----Blog post
Yes... that's 8 nodes in the tree, all referencing one. Clicking any node expands and highlights the top one.
Now the tricky thing is, if I create the blog post by clicking the "Create" button on the upper left, then it works as expected - only one node listed.
Any ideas why this might be happening? Should this be a bug report instead?
I get this in 4.5.2 when creating nodes with usercontrols. Should say that my problem is unrelated to the Blog4Umbraco package descibed above.
After creating node in UC the node shows two times in node tree (same node ID. If i republish it in umbraco and reload nodes the duplicate goes away. This worked fine on my development server.
I've encountered this with other ways of creating nodes with the API, but mostly when trying to automatically create date folders. It often varies between our dev and production sites too, like it will create duplicates on one and not the other. Still not sure what the fix is!
Ernst Utvik: Thanks for the reply, although that wasn't the reply I was hoping for. I'm trying to avoid purchasing MSSQL, since we're already invested in Oracle licenses.
Stephen: Thanks for finding that. I can confirm that the bug you linked is indeed hitting me. I have folder named "2010" with 2 versions with the same versionDate. The row with newest =0 has a null templateID. The row with newest = 1 has the correct templateID. Changing the versionDate solves the duplicate folder problem, and I expect that adding a newest = 1 to the where clause noted in the bug would have the same effect.
Can anyone using Blog 4 Umbraco with MSSQL tell me if the package creates two rows( one with a null templateID) for them as well? You can just do
select * from cmsDocument where versionId in(
select versionId from cmsContentVersion where contentId = [Folder Content ID])
I can't tell if that's a Blog4/MySQL bug, or just the way it works. Blog4 also made 3 rows for the actual blog post.
Hey there. I've come across the same issue, and looking at the DB, it does look like the work item Stephen linked to is correct - Thanks Steven.
I have many nodes showing twice, some 3 times, and the number of repetitions are directly inline with the number of nodes that have the same 'updateDate' property in the cmsDocument table.
Hmm, now to contemplate if I just fix the migrated data, or go about compiling the source and replacing a DLL...
I was banging my head against the wall wondering why a MSSQL install didn't have this problem but it happened in MySQL every time - the reason is that the MySQL TIMESTAMP type has a maximum precision of seconds, whereas MSSQL goes to milliseconds.
This makes collisions FAR more likely (almost inevitable) in MySQL.
If you didn't want to mess around with the core Umbraco or the Blog 4 Umbraco code (I don't):
I think a possible solution would be to write a trigger that checks for duplicate contentid / versiondate in the cmscontentversion table and knocks the versiondate forward by a second. I haven't tried that yet though.
If the trigger doesn't work then an incredibly hacky solution would possibly be achievable with an ApplicationBase (using it as a trigger, basically).
Also, the problem goes away when you publish any later changes, as the latest version is then a unique timestamp.
Hi Josh, the project I was having this on has been on hold for a bit so I have not looked into those solutions further; when I do get back to it, if there has not been an actual fix I'll post any workarounds here.
Okay, the fix is not in the current stable release of 4.6.1. I'm not really sure how the changesets get applied tbh, but anyway, this still happens in 4.6.1.
Re: my suggested fixes:
You can't do it with a trigger; the VERSIONDATE column is set using a default value of CURRENT_TIMESTAMP; on a BEFORE INSERT trigger this happens after it fires, regardless of what you set the insertion value to. On an AFTER INSERT trigger you have no access to the table at all.
I have not tried the ApplicationBase technique as I'm not too up on the API.
Hi i dont know if this is the right solution for the main topic, but I have been sitting with the same error. The latest Juno version 4.6.1, and MySQL. I have made an usercontol to create new nodes, and i get duplicated nodes every time because of the VERSIONDATE is the same.
My solution had been to add this line to my usercontrol.
Thread.Sleep(1500);
Before the publish line, so it gives the code a 1,5 sec pause (in reality it should be okay with a 1 sec), so the VERSION of the published version is a second newer :-)
That worked for me... hope it is an answer for some in this thread :-)
I'm suddenly having this issue after having republished large portions of our website. Suddenly our top menu (Razor macro) is showing some nodes more than once. WTF?
Here's the screencap of the top menu (both "About" menu items point to the same node):
The Razor script creating that top menu:
@foreach (var item in Model.AncestorOrSelf(1).Level1s) { <li><a href="@item.Url">@item.Name</a></li> }
And this is on Umbraco 6.0 (recent upgrade from 4.11.4).
Umbraco makes me so nervous; days ahead of potentially rolling this out and so many buggy issues (high CPU/RAM usage, having to republish frequently, etc.)
The workitem is not on Codeplex anymore... currently discussion the issue w/Core team to check if we need to create an issue in the new tracker.
Would be "major" issue I guess.
@eric: please report all isses that you found. Maybe create a new post in Our just listing all your problems (and link it from here) so we can address them. Upgrading to 6.0.0 should not be a scary experience. If it is... then some things need to be fixed, and having your input would be quite precious!
@Eric You only write that you are seeing this after republishing large portions of your site. Does this mean that you don't see two About nodes in the backoffice?
And another question: are you running the site on a MSSQL, SQL CE or MySql database ?
Content tree lists nodes multiple times
I just installed Blog4Umbraco, I'm using umbraco 4.0.3 in Firefox, and I tried creating a second blog. On the second blog, when I create a Blog Post by right clicking on the 2nd blog and selecting Create, then after I publish and reload the tree, each node is listed twice in the content tree even though they all reference the same node. It looks like:
Blog2
-2010
--5
---4
----Blog post
---4
----Blog post
--5
---4
----Blog post
---4
----Blog post
-2010
--5
---4
----Blog post
---4
----Blog post
--5
---4
----Blog post
---4
----Blog post
Yes... that's 8 nodes in the tree, all referencing one. Clicking any node expands and highlights the top one.
Now the tricky thing is, if I create the blog post by clicking the "Create" button on the upper left, then it works as expected - only one node listed.
Any ideas why this might be happening? Should this be a bug report instead?
Bump!
Anyone found a solution?
I get this in 4.5.2 when creating nodes with usercontrols. Should say that my problem is unrelated to the Blog4Umbraco package descibed above.
After creating node in UC the node shows two times in node tree (same node ID. If i republish it in umbraco and reload nodes the duplicate goes away. This worked fine on my development server.
Tested some more and found I also get the same error with blog4umbraco. Do you use a mySql database Eric?
No, we were using SQL Server.
I've encountered this with other ways of creating nodes with the API, but mostly when trying to automatically create date folders. It often varies between our dev and production sites too, like it will create duplicates on one and not the other. Still not sure what the fix is!
Were you ever able to track this down? I'm having the same problem with duplicate nodes using Blog 4 Umbraco and MySql.
Changing to a mssql database fixed the problem for me..
Could it be linked to this: http://umbraco.codeplex.com/workitem/29443 ?
Especially since you mention automatic creation of folders (think autofolders).
Ernst Utvik: Thanks for the reply, although that wasn't the reply I was hoping for. I'm trying to avoid purchasing MSSQL, since we're already invested in Oracle licenses.
Stephen: Thanks for finding that. I can confirm that the bug you linked is indeed hitting me. I have folder named "2010" with 2 versions with the same versionDate. The row with newest =0 has a null templateID. The row with newest = 1 has the correct templateID. Changing the versionDate solves the duplicate folder problem, and I expect that adding a newest = 1 to the where clause noted in the bug would have the same effect.
Can anyone using Blog 4 Umbraco with MSSQL tell me if the package creates two rows( one with a null templateID) for them as well? You can just do
I can't tell if that's a Blog4/MySQL bug, or just the way it works. Blog4 also made 3 rows for the actual blog post.
Hey there. I've come across the same issue, and looking at the DB, it does look like the work item Stephen linked to is correct - Thanks Steven.
I have many nodes showing twice, some 3 times, and the number of repetitions are directly inline with the number of nodes that have the same 'updateDate' property in the cmsDocument table.
Hmm, now to contemplate if I just fix the migrated data, or go about compiling the source and replacing a DLL...
This is definitely work item 29443.
I was banging my head against the wall wondering why a MSSQL install didn't have this problem but it happened in MySQL every time - the reason is that the MySQL TIMESTAMP type has a maximum precision of seconds, whereas MSSQL goes to milliseconds.
This makes collisions FAR more likely (almost inevitable) in MySQL.
If you didn't want to mess around with the core Umbraco or the Blog 4 Umbraco code (I don't):
I think a possible solution would be to write a trigger that checks for duplicate contentid / versiondate in the cmscontentversion table and knocks the versiondate forward by a second. I haven't tried that yet though.
If the trigger doesn't work then an incredibly hacky solution would possibly be achievable with an ApplicationBase (using it as a trigger, basically).
Also, the problem goes away when you publish any later changes, as the latest version is then a unique timestamp.
Oh sh!t - I have finally found the actual forum thread with the reason for this nightmare!
Though unfortunately no solution (directly)...
Is there any fix seen as possible for this? @Rob have you attempted succesfully any of the above?
IE: an event actionhandler that runs after the multiple node creation, to clean them up? Or Anyone with an update patch_fix for the actual issue???
Thanks
Josh
Hi Josh, the project I was having this on has been on hold for a bit so I have not looked into those solutions further; when I do get back to it, if there has not been an actual fix I'll post any workarounds here.
Josh, just noticed that the workitem has been closed with a fix - I've not tried it yet though.
Okay, the fix is not in the current stable release of 4.6.1. I'm not really sure how the changesets get applied tbh, but anyway, this still happens in 4.6.1.
Re: my suggested fixes:
Hi i dont know if this is the right solution for the main topic, but I have been sitting with the same error. The latest Juno version 4.6.1, and MySQL. I have made an usercontol to create new nodes, and i get duplicated nodes every time because of the VERSIONDATE is the same.
My solution had been to add this line to my usercontrol.
Thread.Sleep(1500);
Before the publish line, so it gives the code a 1,5 sec pause (in reality it should be okay with a 1 sec), so the VERSION of the published version is a second newer :-)
That worked for me... hope it is an answer for some in this thread :-)
/Peter
It's a good workaround, but it doesn't help me unfortunately as I didn't want to get into messing with the Blog 4 Umbraco source!
I have packaged my site best i could, and reinstalled on mssql... re-importing and linking media!
What a job, but really no easy way around the blog 4 umbraco issue that i could see.
Until this is resolved in the tree - only selecting limit 1, I will be using mssql.
I'm suddenly having this issue after having republished large portions of our website. Suddenly our top menu (Razor macro) is showing some nodes more than once. WTF?
Here's the screencap of the top menu (both "About" menu items point to the same node):
The Razor script creating that top menu:
@foreach (var item in Model.AncestorOrSelf(1).Level1s) {
<li><a href="@item.Url">@item.Name</a></li>
}
And this is on Umbraco 6.0 (recent upgrade from 4.11.4).
Umbraco makes me so nervous; days ahead of potentially rolling this out and so many buggy issues (high CPU/RAM usage, having to republish frequently, etc.)
The workitem is not on Codeplex anymore... currently discussion the issue w/Core team to check if we need to create an issue in the new tracker.
Would be "major" issue I guess.
@eric: please report all isses that you found. Maybe create a new post in Our just listing all your problems (and link it from here) so we can address them. Upgrading to 6.0.0 should not be a scary experience. If it is... then some things need to be fixed, and having your input would be quite precious!
@Eric You only write that you are seeing this after republishing large portions of your site. Does this mean that you don't see two About nodes in the backoffice?
And another question: are you running the site on a MSSQL, SQL CE or MySql database ?
- Morten
Using SQL Server 2008, and the duplicate nodes were only appearing via the Razor macro, not in the BackOffice.
That said, having applied 6.0.1 nightly build seems to have corrected the double-node problem.
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.