Children of Root Node that are of a Specific Document Type
Once again I am being challenged by this Razor malarky! All I want to do is get the first child node under the root that is of a specific document type so that I can list out links to their child pages but no matter what I try the "Enumeration yielded no results"!
Added OrSelf (to make sure that it also works on the root node) and level 1 to make sure you go to the root node. Then added First() in the end to get the first found node. Then you can add .Children to put it in a foreach.
This is almost the exact example from my Razor Examples project, ContentSubMenu.cshtml if you want to have a look.
Yes running 4.7.1, I've even tried copying and pasting the doctype alias from the umbraco.config file to be double sure - I miss XSLT already! I suppose I could try and cheat and use @Model.XPath ?
This is a pretty clean install as it's a new project with only one package so far which is the Char Limit datatype.
@Model.AncestorOrSelf()
The above returns me a DynamicNode as expected and that node is the homepage, however even that shows a Child node count as zero which it isn't. To add to confusion the OOTB Sitemap Razor script works fine so it's not as though the data is not there for whatever reason.
OK so either there is possibly a bug with SQL CE installs or something wasn't very well in my installation however I have sorted it. In case it was an issue with umbraco.config I thought I would try /umbraco/dialogs/republish.aspx?xml=true and hitting republish entire site however I hit an exception so I deleted umbraco.config, touched the web.config and we're up and running again.
Ouch! Glad it's working now though, hope it's not a SQL CE bug, 'cause I can't for the life of me think what could've corrupted your umbraco.config so badly.
I don't actually think the umbraco.config file was in fact corrupt I think it was out of date. The node that I was trying to get a hold of was not previously in the root and so I suspect that the umbraco.config file was not updated when it was moved. I guess it's possible that it could be related to the issue that I reported on Codeplex but wihtout trawling the source I can't say for sure.
Crap, I do hope it's not a SQL CE issue, I did go through that code a few times and it seemed to be okay, would be great if your were able to repdroduce this though, might be a CE thing after all. Frustrating that CE is just a liiiiittle bit different from SQL proper and spotting errors like these can get tough.
Children of Root Node that are of a Specific Document Type
Once again I am being challenged by this Razor malarky! All I want to do is get the first child node under the root that is of a specific document type so that I can list out links to their child pages but no matter what I try the "Enumeration yielded no results"!
I've tried the following with no success:
@Model.Ancestor().Children.Where("NodeTypeAlias == \"doctypeAlias\"")@Model.Ancestor().doctypeAlias@Model.Ancestor().Descendants("doctypeAlias")Am I doing something very obviously wrong?
I'm still learning myself, but I think either of these should work. I'm not quite sure how Ancestor() works...
@Model.AncestorOrSelf("Home").Textpages-Tom
You said it yourself, you want the first one.. :-)
@Model.AncestorOrSelf().Children.Where("NodeTypeAlias == \"doctypeAlias\"").First()Added OrSelf (to make sure that it also works on the root node) and level 1 to make sure you go to the root node. Then added First() in the end to get the first found node. Then you can add .Children to put it in a foreach.
This is almost the exact example from my Razor Examples project, ContentSubMenu.cshtml if you want to have a look.
I should have added that I had already tried
...which still doesn't return any result. Your example above also returns null :p
Welll ... check the doctypeAlias (casing, spelling). Try without the Where, if you still get null then you've got other problems. ;-)
You are running 4.7.1 (not 4.7.0) right?
Yes running 4.7.1, I've even tried copying and pasting the doctype alias from the umbraco.config file to be double sure - I miss XSLT already! I suppose I could try and cheat and use @Model.XPath ?
This is a pretty clean install as it's a new project with only one package so far which is the Char Limit datatype.
The above returns me a DynamicNode as expected and that node is the homepage, however even that shows a Child node count as zero which it isn't. To add to confusion the OOTB Sitemap Razor script works fine so it's not as though the data is not there for whatever reason.
How have you determined the childnode count?
This works for me:
So, if the sitemap works, there must be something wrong in your code, are you sure you're using AncestorOrSelf and not the plural AncestorsOrSelf?
I'd be happy to look at the entire site if you can zip it up (don't forget the DB, but I think you're using SQL CE, right?).
Ps: no, you're not allowed to cheat with XPath!! ;-)
OK so either there is possibly a bug with SQL CE installs or something wasn't very well in my installation however I have sorted it. In case it was an issue with umbraco.config I thought I would try /umbraco/dialogs/republish.aspx?xml=true and hitting republish entire site however I hit an exception so I deleted umbraco.config, touched the web.config and we're up and running again.
The following examples now work:
@Model.AncestorOrSelf().DocTypeAlias.First()@Model.Ancestor().Children.Where("NodeTypeAlias == \"doctypeAlias\"").First()Ouch! Glad it's working now though, hope it's not a SQL CE bug, 'cause I can't for the life of me think what could've corrupted your umbraco.config so badly.
I don't actually think the umbraco.config file was in fact corrupt I think it was out of date. The node that I was trying to get a hold of was not previously in the root and so I suspect that the umbraco.config file was not updated when it was moved. I guess it's possible that it could be related to the issue that I reported on Codeplex but wihtout trawling the source I can't say for sure.
Crap, I do hope it's not a SQL CE issue, I did go through that code a few times and it seemed to be okay, would be great if your were able to repdroduce this though, might be a CE thing after all. Frustrating that CE is just a liiiiittle bit different from SQL proper and spotting errors like these can get tough.
is working on a reply...