Brad,

instead of using $currentPage, use:

<xsl:variable name="myStartNode" select="umbraco.library:GetXmlNodeById(id)" />

(id may be hardcoded, but could also pass this as a parameter from the macro that references the xslt)

Hope this helps.

Regards,

/Dirk

First of all you can try display your xml using textarea trick:

<textarea>
 <xsl:copy-of select="." />
</textarea>

You also can try remove first dot in for-each select statement

Petr

You will not need the "./" before both selects, I suggest you do it a bit more like this:

<xsl:template match="/">
 <xsl:for-each select="$currentPage/ancestor-or-self::node [@alias = 'panelText']">

   <xsl:value-of select="."/>

 </xsl:for-each>

</xsl:template>

So what this does is walk from the currentPage all the way up to the highest node (called node) then finds everything with the Alias of panelText. The select just shows that panelText ("." means: the current element's value).

I think what you're missing is a little primer on how xlst in umbraco works. I can see from your post that you've created some xslt in a xslt-editor, and tested your xslt directly on the umbraco.config file, which should work fine if the xslt files in umbraco was aused with this entire file when doing the transform.

Problem is they aren't. When umbraco runs your xslt-file it doesn't have the usual access to the root of the umbraco.config file. The xml-file you're transforming has some extra xml content that is not present in umbraco.config, you may imagine an xml-document with the umbraco.config present in a subnode to the root, other subnodes contains stuff like macro parameters etc.

That's why everybody uses the $currentPage parameter, which is a parameter pointing at the node of the currentpage in the umbraco.config file, if you need acces to the root of the umbraco.config and do a transformation from there you'll have to create a variable that point to the root first, which can be done like this:

<xsl:variable name="umbRoot" select="$currentPage/ancestor::root" />

This variable can then be used when you're doing transformations that contains code that starts out from the root of the umbraco.config file.

I can recommend Douglas Robars excellent introduction to xslt in Umbraco.

Regards
Jesper Hauge

>>> I think what you're missing is a little primer on how xlst in umbraco works.

I think you are right and until you wrote this message I had no reason to asssume that XSLT in Umbraco is somehow different. 

Even that nice tutorial you directed me to (which I read earlier today) says this about currentPage

"What page is the website visitor currently viewing? That is what the currentPage parameter is used for. Of all the pages in your site, currentPage will tell you which one is being viewed.

The currentPage parameter is automatically populated by umbraco. It is referenced as $currentPage in your XSLT and you will use it a lot, as we'll see in future articles."

Kind of plays down the importance.

Thanks for the tips and explaination of this works. I'm off to give it a try.

I got this working using Dirks suggestion using GetXmlNodeById().Thanks Dirk. Here is the final code.

<xsl:for-each select="umbraco.library:GetXmlNodeById(1062)/node">
<xsl:sort select="@sortOrder" />
    <div class="news">
          <xsl:value-of select="data [@alias='panelText']" />
    </div>
    <xsl:if test="data [@alias='itemLink'] != ''">
        <a class="newsAnchor">
            <xsl:attribute name="href">
                            <xsl:value-of select="data [@alias='itemLink']"/>
                       </xsl:attribute> 
            Read More >
        </a>
        <br></br>
    </xsl:if>
    
</xsl:for-each>

Thanks to all that responed.. Especially Jesper who gave some valuable info about how Unbraco works with XSLT (or visa versa). Info I could not find documented anywhere.

One question though.. One would have to assume that the ID of a node, never changes for this to keep working. Right? I do hate hardcoding stuff like this but I got so held up (loosing money)  I was just happy to get it working.

Brad

Hi Brad

Glad you could use it.

You're right, the id of a page doesn't change in its lifetime, but you should be aware, that deleting the page (node) and creating a new with identical property values, would create a node with a new id. This could happen if your customer deletes the panelitems node by accident.

I situations like these I tend to create a document type to be used for holding panelitems alone, and then create a node of this type holding the panelitems in the root of the content tree, I then give this panelitems node the same nodename as the node holding the root of the website content:

Root
    - mydomain.com (website)
        - content page 1 (textpage)
        - content page 2 (textpage)
        - ..
    - mydomain.com (panelitems)
        - panelitem 1 (panelitem)
        - panelitem 2 (panelitem)
        - ..

Document type aliases in (). With this structure I can add more domains (like extra languages) and panelitems folders and still only use the following xslt to render panelitems for a website:

<xsl:variable name="webRoot" select="$currentPage/ancestor-or-self::node[@nodeTypeAlias='website']" />
<xsl:variable name="panelitemsRoot" select="$currentPage/ancestor::root/descendant::node[@nodeTypeAlias='panelitems' and @nodeName = $webRoot/@nodeName]" />

<!-- xslt guff -->
<xsl:for-each select="$panelitemsRoot/node">
    <!-- Your rendering code here -->
</xsl:for-each>

Regards
Jesper Hauge

I'm happy to see that my site structure is exactly like yours. (maybe I did not expain it right) .. I have the site pages and the PanelItems in seperate nodes directly under root.

And thanks for your code sample.. Consider it borrowed. :)

is working on a reply...