I want to select only those nodes which inherit from a base document type - as far as I can tell, nodeTypeAlias only uses the alias of the current node and doesn't take its inheritance into account.
<xsl:for-each select="$currentPage/ancestor-or-self::node [@level=1]/node [string(data [@alias='umbracoNaviHide']) != '1'][((( inherits from document type 'xxxx' )))]">
So it may need to be a case of finding from the document type in 'settings' which nodes inherit and putting the nodeTypeAlias' in the for-each manually...
Mike, could you hook on to any unique properties on the parent docType?
For example, lets say you have a parent docType called "BaseDocType" and a property in it called "inheritedDocType". Then in the XSLT you can do this:
<xsl:for-each select="$currentPage/ancestor-or-self::node[@level=1]/node[@nodeTypeAlias != 'BaseDocType' and count(data[alias='inheritedDocType']) > 0 and string(data[@alias='umbracoNaviHide']) != '1']">
<xsl:value-of select="@nodeName" />
</xsl:for-each>
Here is what is happening in the select... the first condition is checking that it not the base doc-type, the second is checking if it has the inherited property, and the third is your usual 'umbracoNaviHide' test.
It would be much nicer to have a node-level attribute/property called "parentNodeAlias", but then where do you draw the line, as you have several nested doc-types ... unless they went down the @path route? (with comma-separated doc-type ids).
Under my home page, I have several pages (some standard pages, maybe some other pages which inherit from a standard page - like a 'section page'), but I also have a couple of folders for pages which will go in header and footer navigation elements. In my primary nav xslt, I'm trying to exclude everything under the home element which isn't something which inherits from a standard page.
I could list all the inherited types, or conversely I could select everything except the folder types - I just thought that if there was a quick way to select nodes based on their inherited type, that would be a tidy way of doing it.
I want to keep the header and footer folders underneath the 'home' node because there's a chance this could be a multilingual site. Lots to consider... :-)
I usually have a top level node called "site" which holds site wide parameters, this could be where your multiple lingual seperation happens as you'd have multiple site's each with their own "home" / "footer" / "header" sections.
One of the advantages of Master Templates is that all of the children inherit all of the data types. Since this is the case, you can add a datatype to the master template, similar to the UmbracoHideNavi checkbox that the navigation will look for. Since the folder's don't inherit this data type, then the folders will not display.
That sounds interesting --- quick question though - how do you prevent NiceUrl links from reading "/home/section/page.aspx"? (I wouldn't want the "/home/" part in there...
The hideTopLevelNodeFromPath setting is already true; Chris was suggesting a structure like this, to enable a multi-lingual approach, but also to logically separate normal site content from header and footer elements:
+ Content (root)
+ Site
+ Home
(normal site content pages)
+ Header
(header navigation pages - glossary, downloads, site map etc)
Taking it back to the original problem, I'm not sure why you'd want to do it this way. Obviously there's more than one way to skin a cat, but for "footer links" that don't fit anywhere else I usually put them under the homepage as with any other content page and set umbracoNaviHide to be true. Then use treeMultiPicker on the homepage to allow editors to create the footer nav.
The advantage of this is that often editors want to include "normal" pages in the footer, and using the treemultipicker allows them to select any page in the site to be added to the footer and reorder them with drag & drop.
Then to complete that the following xslt should display the footer nav on every page
Using this method it may seem to clutter the main level under the homepage in the tree, but these (privacy policy) are real site pages so why should they be hidden away? If you need to hide them, then create a folder called something innocuous like "site" and pop them in there.
Hi there - it looks like you solved the problem, but I thought I'd toss in my 2 cents because I had a similar issue and used a bit of a workaround - I'm relatively new to Umbraco so please feel free to shoot it down ;)
Due to the project specs and the way I've handled the inheritance, I need to display all pages that inherit from a specific master page and have a given tag - I used a naming convention and filtered by "contains" rather than an exact match to the parent type - every document type under the "ContentPage" doc type has "ContentPage" in its alias (ie "ContentPage2Column"):
nodeTypeAlias - how to get inherited document type?
I want to select only those nodes which inherit from a base document type - as far as I can tell, nodeTypeAlias only uses the alias of the current node and doesn't take its inheritance into account.
<xsl:for-each select="$currentPage/ancestor-or-self::node [@level=1]/node [string(data [@alias='umbracoNaviHide']) != '1'][((( inherits from document type 'xxxx' )))]">
Any ideas?
It doesn't seem to be stored in the node
So it may need to be a case of finding from the document type in 'settings' which nodes inherit and putting the nodeTypeAlias' in the for-each manually...
Unless someone has more info?
Dan
Mike, could you hook on to any unique properties on the parent docType?
For example, lets say you have a parent docType called "BaseDocType" and a property in it called "inheritedDocType". Then in the XSLT you can do this:
<xsl:for-each select="$currentPage/ancestor-or-self::node[@level=1]/node[@nodeTypeAlias != 'BaseDocType' and count(data[alias='inheritedDocType']) > 0 and string(data[@alias='umbracoNaviHide']) != '1']"> <xsl:value-of select="@nodeName" /> </xsl:for-each>Here is what is happening in the select... the first condition is checking that it not the base doc-type, the second is checking if it has the inherited property, and the third is your usual 'umbracoNaviHide' test.
It would be much nicer to have a node-level attribute/property called "parentNodeAlias", but then where do you draw the line, as you have several nested doc-types ... unless they went down the @path route? (with comma-separated doc-type ids).
Let me know if it works out!
Cheers, Lee.
Hi Mike,
I think Dan is probably right. What are you trying to do? Maybe there is another way to solve your problem?
Chris
Under my home page, I have several pages (some standard pages, maybe some other pages which inherit from a standard page - like a 'section page'), but I also have a couple of folders for pages which will go in header and footer navigation elements. In my primary nav xslt, I'm trying to exclude everything under the home element which isn't something which inherits from a standard page.
I could list all the inherited types, or conversely I could select everything except the folder types - I just thought that if there was a quick way to select nodes based on their inherited type, that would be a tidy way of doing it.
Thanks for your help,
Mike
If I understand you correctly, you currently have the following structure:
home
home/blog/blog post
home/etc.....
home/footerfolder/terms and conditions
home/headerfolder/contact us
Why not move the footer & header folders up to the root of your content structure?
Another option is to add a couple more parameters, I.e. umbracoNaviFooterHide / umbracoNaviHeaderHide ( or the opposite... "show" )
Cheers,
Chris
I want to keep the header and footer folders underneath the 'home' node because there's a chance this could be a multilingual site. Lots to consider... :-)
Personally I think the true/false switches for header/footer links (as Chris mentioned) is the way to go ... it's a more scalable solution.
Hi,
I usually have a top level node called "site" which holds site wide parameters, this could be where your multiple lingual seperation happens as you'd have multiple site's each with their own "home" / "footer" / "header" sections.
Just an idea :)
Cheers,
Chris
One of the advantages of Master Templates is that all of the children inherit all of the data types. Since this is the case, you can add a datatype to the master template, similar to the UmbracoHideNavi checkbox that the navigation will look for. Since the folder's don't inherit this data type, then the folders will not display.
Chris,
That sounds interesting --- quick question though - how do you prevent NiceUrl links from reading "/home/section/page.aspx"? (I wouldn't want the "/home/" part in there...
Cheers,
Mike
Does the "hideTopLevelNodeFromPath" setting not do that? It's in umbracosettings.config (I think!)
@Dan: "umbracoHideTopLevelNodeFromPath" is in the Web.config ;-)
Ah, probably should check these things instead of dropping disclaimers!
The hideTopLevelNodeFromPath setting is already true; Chris was suggesting a structure like this, to enable a multi-lingual approach, but also to logically separate normal site content from header and footer elements:
+ Content (root)
+ Site
+ Home
(normal site content pages)
+ Header
(header navigation pages - glossary, downloads, site map etc)
+ Footer
(footer navigation pages - accessibility, privacy policy etc)
Taking it back to the original problem, I'm not sure why you'd want to do it this way. Obviously there's more than one way to skin a cat, but for "footer links" that don't fit anywhere else I usually put them under the homepage as with any other content page and set umbracoNaviHide to be true. Then use treeMultiPicker on the homepage to allow editors to create the footer nav.
As shown at http://i33.tinypic.com/2uonnt0.jpg
The advantage of this is that often editors want to include "normal" pages in the footer, and using the treemultipicker allows them to select any page in the site to be added to the footer and reorder them with drag & drop.
Then to complete that the following xslt should display the footer nav on every page
Using this method it may seem to clutter the main level under the homepage in the tree, but these (privacy policy) are real site pages so why should they be hidden away? If you need to hide them, then create a folder called something innocuous like "site" and pop them in there.
Hope this helps,
Dan
Hi Dan - this seems like a really tidy solution, thanks for your help.
Mike
Hi there - it looks like you solved the problem, but I thought I'd toss in my 2 cents because I had a similar issue and used a bit of a workaround - I'm relatively new to Umbraco so please feel free to shoot it down ;)
Due to the project specs and the way I've handled the inheritance, I need to display all pages that inherit from a specific master page and have a given tag - I used a naming convention and filtered by "contains" rather than an exact match to the parent type - every document type under the "ContentPage" doc type has "ContentPage" in its alias (ie "ContentPage2Column"):
Is there a more elegant way?
Cheers, Saxon
sigh, new to the boards, sorry about that....
is working on a reply...