This is a much loved and very established package, so it could very well be that I'm interpreting the XSLT incorrectly (particularly as I've done some fairly heavy customisation) but I wanted to put it 'out there' for a second opinion.
The 'choose' statement around line 121 (version 3.0.4) ends with something like this:
<xsl:otherwise> <!-- search only within the SOURCE node specified in the macro and all of its children --> <xsl:call-template name="search"> <xsl:with-param name="items" select="./descendant-or-self::*[@isDoc]"/> </xsl:call-template> </xsl:otherwise>
This is the condition which applies when there is a source node set as a macro parameter, which is, as I understand it, when you want to start your search up through the content tree starting at a particular node.
I had issues when this condition was met though - it just wasn't returning the anticipated nodes in the search results. On initial inspection it seems that this condition is instead just returning descendent (or self) nodes from the current node instead of from the selected source node. I modified it to the following and it now returns what I'd expect:
<xsl:otherwise> <!-- search only within the SOURCE node specified in the macro and all of its children --> <xsl:call-template name="search"> <xsl:with-param name="items" select="umbraco.library:GetXmlNodeById($source)/descendant-or-self::*[@isDoc]"/> </xsl:call-template> </xsl:otherwise>
Like I say, I've customised the search script quite heavily, and haven't done a particularly thorough trace of exactly what's happening, but I wanted to see if anyone could verify this as it might be something to change in 3.0.5 if it is indeed a bug. More than happy to be proven that it isn't! :)
It should work fine, as long as your macro parameter is using the correct type. I suspect your modified macro uses a 'contentPicker' for the 'source' parameter. XSLTsearch uses the 'ContentTree' property type, which will make the difference of sending in either a single ID or a whole chunk of xml.
...which will make the difference of being able to use the current data (in my code) or having to get the node by id (in your code).
Yep, that's probably it. Thanks for the sanity-check Doug!
Edit: If you've found the same Lee then I will investigate further, but I did change the datatype of the macro parameter so Doug's answer sounds entirely likely.
@Lee - I was trying to be clever at the time but if I were to write XSLTsearch again I'd just use a contentPicker and GetXmlNodeById()... nobody (and that includes me from time to time) remembers that there's a contentTree that sends in xml. It's a classic case of being clever rather than being clear.
While there *might* be a *teeny tiny* performance benefit from sending in the xml rather than having to make a second call to retrieve it, I don't think it's significant and not worth the confusion.
I've often wondered what the contentTree macro parameter type does. The world makes a lot more sense now (how did I miss that it passes through a chunk of XML!?)
Possible bug when specifying start node to search
Hi,
This is a much loved and very established package, so it could very well be that I'm interpreting the XSLT incorrectly (particularly as I've done some fairly heavy customisation) but I wanted to put it 'out there' for a second opinion.
The 'choose' statement around line 121 (version 3.0.4) ends with something like this:
This is the condition which applies when there is a source node set as a macro parameter, which is, as I understand it, when you want to start your search up through the content tree starting at a particular node.
I had issues when this condition was met though - it just wasn't returning the anticipated nodes in the search results. On initial inspection it seems that this condition is instead just returning descendent (or self) nodes from the current node instead of from the selected source node. I modified it to the following and it now returns what I'd expect:
Like I say, I've customised the search script quite heavily, and haven't done a particularly thorough trace of exactly what's happening, but I wanted to see if anyone could verify this as it might be something to change in 3.0.5 if it is indeed a bug. More than happy to be proven that it isn't! :)
It should work fine, as long as your macro parameter is using the correct type. I suspect your modified macro uses a 'contentPicker' for the 'source' parameter. XSLTsearch uses the 'ContentTree' property type, which will make the difference of sending in either a single ID or a whole chunk of xml.
...which will make the difference of being able to use the current data (in my code) or having to get the node by id (in your code).
cheers,
doug.
Curious about this too now. Just downloaded 3.0.4 from the project page, and took a look... and I think you're right - looks like a bug.
The "./descendant-or-self" wouldn't even use $currentPage, but the <macro> XML (which contains the parameters).
Good spot, sure Doug will update accordingly.
Cheers, Lee.
Yep, that's probably it. Thanks for the sanity-check Doug!
Edit: If you've found the same Lee then I will investigate further, but I did change the datatype of the macro parameter so Doug's answer sounds entirely likely.
Ah-ha, just saw your reply Doug... having the ContentTree property type makes sense! (e.g. it sends the node XML!)
#h5is :-)
Cheers, Lee.
@Lee - I was trying to be clever at the time but if I were to write XSLTsearch again I'd just use a contentPicker and GetXmlNodeById()... nobody (and that includes me from time to time) remembers that there's a contentTree that sends in xml. It's a classic case of being clever rather than being clear.
While there *might* be a *teeny tiny* performance benefit from sending in the xml rather than having to make a second call to retrieve it, I don't think it's significant and not worth the confusion.
cheers,
doug.
I've often wondered what the contentTree macro parameter type does. The world makes a lot more sense now (how did I miss that it passes through a chunk of XML!?)
Thanks Doug, always great to learn something new.
is working on a reply...