When you know at which level the parent node of Settings resides AND the Settings node is always of the same Document Type, you could use something as simple as (where "<" and ">" are placeholders):

$currentPage/ancestor-or-self::*[@isDoc and @level = <LevelOfParentOfSettings>]/Settings

The ancestor-or-self XPath "axis" does the hard work for you, it will look from (and including) the current node up until it finds a node that has an "isDoc" property AND is of the required level. Looking at your schema, my best guess is each "Website X" node is at level 1 (one).

Thank you for the response, I assume your code is using the new XSLT schema which I haven't managed to get my head around yet so I am still using the old schema but hopefully I will be able to write something based on your idea.

Ok I appear to be struggling to convert what you suggested into the old schema, any help would be appreciated. So far I have got the following but it does not appear to be showing any results, I have tried adjusting the level but that did not help. Any suggestions as to what I'm missing?

<xsl:for-each select="$currentPage/ancestor-or-self [@level=2 and @nodeTypeAlias = 'Settings']">
   <xsl:value-of select="data [@alias = 'testProperty']"/>
</xsl:for-each>

I did try it with :: after ancestor-or-self similar to yours but that throws an XSLT error

After the "axis" ancestor-or-self, you need to specify the node you're looking for, which is just called "node" in the legacy schema, while it can be anything (as in any document type name) in the new schema, hence the "*" in my first reply.

So it would become something like (for the legacy schema):

<xsl:for-each select="$currentPage/ancestor-or-self::node[@level=2 and @nodeTypeAlias = 'Settings']">
        <xsl:value-of select="data [@alias = 'testProperty']"/>
</xsl:for-each>

Thank you for the quick response, I tried what you said but it is not displaying any results, as a test I tried the following code and it just displayed "Pages" which suggest to me that it is only search the actual node in the level above the pages and not all the nodes on that level, any ideas what I'm doing wrong? This is the code I used to test:

<xsl:for-each select="$currentPage/ancestor-or-self::node[@level=2]"> 
       <xsl:value-of select="@nodeName"/>
</xsl:for-each> 

It's almost like I need something else to tell it to search all the nodes on level 2

Ok I think I may have cracked it using the following code, not sure if this is best practise of if there is a better way to do this? Please let me know if there is:

<xsl:for-each select="$currentPage/ancestor-or-self::node[@level=1]/node[@nodeTypeAlias = 'Settings']"> 
     <xsl:value-of select="data [@alias = 'testProperty']"/>

</xsl:for-each> 

The "ancestor-or-self" axis only looks up the chain. The "chain" starts with the "$currentPage" in this case, and goes all the way up, until it finds a "node" that has a attribute "level" that has a value of "1" (or "2" or whatever other value you specify). Level 1 happens to be the "Website" node. It then tries to find all children (of the "Website" node just found) of type "node" that have a property "nodeTypeAlias" that has a value of "Settings". Level "2" didn't work, because that is your "Pages" node (looking up from the $currentPage). So if you would want all level 2 nodes under Website, you will first (in XSLT) go up to Website (level 1 and/or nodeTypeAlias "Website) and next, select all children. If you would want to select all level 2 nodes regardless of their chain you would go up to the root ($currentPage/ancestor::root) and select all nodes on level 2 ($currentPage/ancestor::root//node[@level = 2]), where // just says "any descendant" that matches the selector.

If you have (remote desktop) access to the server itself, I would advice you to take a look at the umbraco.config file (I think it's in App_data in 4.5). It's the XML file that actually "drives" the XSLT processor. This will give you a good feeling of how the XML nodes are nested and what the difference is between "@attribute" and "data[@alias = 'aliasType']" properties. And I would advice you to use the new schema, since it is much more "human" readable than the old schema.

As to your question whether this is "good practice" (concerning the Settings node). Is there any reason why you wouldn't want these properties directly on the "Website" node (e.g. neatly grouped on one tab)? It seems like you're just giving yourself a hard time creating some kind of "property bag" (the "Settings" node), while these Settings might as well just live on the Website node itself as properties.

Hi,

Thanks for your response, I have took your advice and now have the following structure, the only problem is that now by going to the URL which take you to the /default.aspx page it does not show my home page, I have republished the site to clear the cache but still no joy, the only way I can get to the homepage is by going to /home.aspx. My structure is now as follows:

Website 1                              (Setting are now defined on this node)
      - Home
      - Page 1
      - Page 2

Website 2                              (Setting are now defined on this node)
      - Home
      - Page 1
      - Page 2

That raises the question why you wouldn't want the "Home" node and the "Website" node to be one and the same? Cause now, the "Website" nodes are just an empty shell. Try to envision the 'friendly URL's you're trying to achieve and implement the site's hierarchy accordingly. I often use the following hierarchy:

Website 1 (Home)
- Page 1
- Page 2
-- Page 2.1
- Page 3

Website 2 (Home)
- Page 1
- Page 2
-- Page 2.1
- Page 3

When there are e.g. multiple languages/channels it might become something like:

Multilingual Website
- EN (Home)
-- Page 1
-- Page 2
--- Page 2.1
-- Page 3
- DE (Home)
-- Page 1
-- Page 2
--- Page 2.1
-- Page 3
- NL (Home)
-- Page 1
-- Page 2
--- Page 2.1
-- Page 3
- FR (Home)
-- Page 1
-- Page 2
--- Page 2.1
-- Page 3

Using URL rewriting, relations between nodes and some IP geolocation and browser language sniffing, you can make a 'best in class' multilingual site.

I hope I didn't drift off topic too much...

Hi,

Thanks for the response, the structure you mentioned is the very thing that I was trying to move away from in the first place because people found it confusing that the pages were underneath the home folder and the fact that settings that apply to the whole site such as a logo etc were being defined on the homepage node when in fact they apply to the whole site. This is the reason I wanted it so that the homepage was on the same level as the other pages and then there was a settings node but as you suggested I can put the settings on the website node.

OK, now I understand, it's a usability problem for editors.

You could put this property umbracoInternalRedirectId on your website node and let it refer to the "Home" node. You would have to do this for every "Website". Refer to the wiki page for more info. I've never used it on a level 1 node, so please test this thoroughly!

is working on a reply...