Am experiencing a weird issue in Umbraco v6.0.2 (in MVC mode)
I've got the following code in a partial view:
@foreach (var mediaItem in mediaFolder.Descendants().OrderBy("UpdateDate desc").Where("Visible")) { <p>@mediaItem.Name</p> }
Which gives me the following output:
good file good file test folder more files more files test 2 test 2 Test Test Other Documents Deeds
But here's what my media tree looks like:
Is there any reason why this is? The media items which are folders also appear twice upon first creation but then only once, when they have their own child node.
I've tried limiting the descendants by level but that doesnt seem to do anything to the output unless I go to a level so deep there is no output at all. e.g
mediaFolder.Descendants(5)
is descendants just broken in 6.02 for the MVC version, or am I doing something stupidly wrong?
if I use children and loop within that it seems to behave as expected. e.g
@foreach (var m in mediaFolder.Children().Where("Visible")) { <h2>@m.Name</h2> foreach (var files in m.Children().Where("Visible")) { if (@files.HasProperty("umbracoFile")){ <p><a href="@files.Url">@files.Name</a></p> } } }
works and doesnt give me any double-ups.
anything wrong with what I'm doing? I dont quite get why when using descendants() items are appearing twice.
thanks for the reply, Good point! I dont have a umbracoNaviHide property. I think I originally put in the .Where("Visible") test out of frustration because of the double-up.... unfortunately taking it back out doesnt change anything.
DescendantsOrSelf() returns the current node as well (to be expected) so that part is working. unfortunately no change in the duplicated descendant nodes.
any other ideas? Now it seems I also get unexpected results even with my regular Children() loop depending on where the file first gets created. if I create the media item underneath a subfolder, its fine, but If I create it at a level above and then move it underneath, it doesnt seem to register the fact that its now a child of the other node where its been moved to.
Is there some sort of index cache in the MVC version that needs to be recreated? similar to doing a 'republish entire site'?
further to the above, If I resave my media item after moving it, my regular Children() loop works as expected again. might head over to http://issues.umbraco.org
have updated to the 6.1 beta and not experiencing problems when items are moved anymore, but still getting my descendants twice when using Descendants() have created an issue here: http://issues.umbraco.org/issue/U4-2094
Part of the reason I suggested the ideas was because I am on 6.0.2 and experiencing an odd issue with media. (I think there was something added to later versions that was said to overcome it, but haven't had a chance to upgrade as it is a live site in early days)
I save in front end after upload by create, cool appears with a currentPage call.
Anything on a loop with descendants, in normal view use, it doesn't appear front-end, if I then save in the Media section it appears.
From your scenario, it leads me to believe that what you have found is actually what is happening, my understanding, although not comprehensive, leads to the engines being different for static and dynamic calls, ie Model.Children, as opposed to Descendants.
If that is the case, does the media need to be saved in two locations currently, to exist for both engines? If so, that is exactly what you are seeing.
What I will do but not until tonight is set up your example, upload via create, then run the loop and see if it appears just once, then save in Media and see if it appears twice.
Either way it could confirm / deny which may be useful in the debugging.
Pleased you raised the issue - think it was deserving.
Thanks for your help, will update when I know some more.
Media Descendants appearing twice?
Am experiencing a weird issue in Umbraco v6.0.2 (in MVC mode)
I've got the following code in a partial view:
@foreach (var mediaItem in mediaFolder.Descendants().OrderBy("UpdateDate desc").Where("Visible"))
{
<p>@mediaItem.Name</p>
}
Which gives me the following output:
good file
good file
test folder
more files
more files
test 2
test 2
Test
Test
Other Documents
Deeds
But here's what my media tree looks like:
Is there any reason why this is?
The media items which are folders also appear twice upon first creation but then only once, when they have their own child node.
I've tried limiting the descendants by level but that doesnt seem to do anything to the output unless I go to a level so deep there is no output at all. e.g
is descendants just broken in 6.02 for the MVC version, or am I doing something stupidly wrong?
if I use children and loop within that it seems to behave as expected. e.g
@foreach (var m in mediaFolder.Children().Where("Visible"))
{
<h2>@m.Name</h2>
foreach (var files in m.Children().Where("Visible"))
{
if (@files.HasProperty("umbracoFile")){
<p><a href="@files.Url">@files.Name</a></p>
}
}
}
works and doesnt give me any double-ups.
anything wrong with what I'm doing? I dont quite get why when using descendants() items are appearing twice.
- Tim
Hi Tim
Have looked at this a few times and scrtached my head.
Will offer something, even if just to remove it from the problem.
Do you have an umbracoNaviHide property on the mediaItem? It would seem odd if you have.
I think it is possible that if that property does not exist, it is saying it is returning the ordered and then the visible.
If you take the ("Visible") out of the descendants, does it then return correctly?
One other thing is to try DescendantsOrSelf(), can't remember why, but I think that there was something on the Descendants() on its own.
Hope it helps
Gary
Hi Gary,
thanks for the reply, Good point! I dont have a umbracoNaviHide property.
I think I originally put in the .Where("Visible") test out of frustration because of the double-up.... unfortunately taking it back out doesnt change anything.
DescendantsOrSelf() returns the current node as well (to be expected) so that part is working. unfortunately no change in the duplicated descendant nodes.
any other ideas?
Now it seems I also get unexpected results even with my regular Children() loop depending on where the file first gets created. if I create the media item underneath a subfolder, its fine, but If I create it at a level above and then move it underneath, it doesnt seem to register the fact that its now a child of the other node where its been moved to.
Is there some sort of index cache in the MVC version that needs to be recreated? similar to doing a 'republish entire site'?
- Tim
further to the above, If I resave my media item after moving it, my regular Children() loop works as expected again.
might head over to http://issues.umbraco.org
It appears I've been experiencing this bug
http://issues.umbraco.org/issue/U4-1653
have updated to the 6.1 beta and not experiencing problems when items are moved anymore, but still getting my descendants twice when using Descendants()
have created an issue here:
http://issues.umbraco.org/issue/U4-2094
- Tim
Hi Tim
Sorry for late reply.
Part of the reason I suggested the ideas was because I am on 6.0.2 and experiencing an odd issue with media. (I think there was something added to later versions that was said to overcome it, but haven't had a chance to upgrade as it is a live site in early days)
I save in front end after upload by create, cool appears with a currentPage call.
Anything on a loop with descendants, in normal view use, it doesn't appear front-end, if I then save in the Media section it appears.
From your scenario, it leads me to believe that what you have found is actually what is happening, my understanding, although not comprehensive, leads to the engines being different for static and dynamic calls, ie Model.Children, as opposed to Descendants.
If that is the case, does the media need to be saved in two locations currently, to exist for both engines? If so, that is exactly what you are seeing.
What I will do but not until tonight is set up your example, upload via create, then run the loop and see if it appears just once, then save in Media and see if it appears twice.
Either way it could confirm / deny which may be useful in the debugging.
Pleased you raised the issue - think it was deserving.
Thanks for your help, will update when I know some more.
Gary
is working on a reply...