A quirk of Sitecore Queries...

It's nearly Christmas, and before I head off for a bit of a holiday, here's a quick bug issue you might encounter. Despite the increasing power and sophistication of the search technologies in Sitecore, sometimes we still need to fall back to good old-fashioned Sitecore Query. A common reason for this is because the query you're writing depends on the structure of the data, not its content. Recently a colleague of mine pointed out some issues to me with the way some queries are resolved, which I thought might be of interest to others.

To see the issue, open your preferred XPath Query building tool (either inside older versions of Sitecore, or in Sitecore Rocks) and pick a context item for the query that's at the bottom of a tree of content. Anything will do, but for example:

You can then write a query using the ancestor-or-self axis, to return this item and those above it up the tree:

All good, so far. (Though the eagle-eyed amongst you may notice that running this query in the "Sitecore XPath" mode returns the results in the opposite order to running it in the "‘Real' XPath" mode. However that's a minor point compared to what follows)

But if you now try to add a position-index term to the query, things don't work quite as you'd expect. In pure XPath you'd expect ancestor-or-self::*[1] to return the context item, and ancestor-or-self::*[2] to return the context item's parent. And if you select the "‘Real' XPath" option for a Rocks query, that is what you'll get. But if you run this query via a Sitecore XPath query you get a different answer:

And it's clearly the wrong answer, as it's returned multiple items where you would expect only one. Other position index values also return the wrong answers.

I have seen this issue in v6.6 and v8.0 – but it's likely that this will occur in other versions too. Sitecore Support have recorded this as a bug, so hopefully it will be corrected in future releases.

On a similar note, you can also see issues with the parent axis. The query parent::* should return the immediate parent of the context item. However what you get is:

That appears to be returning all the children of the parent item. Again, running the query against "real" XPath returns the answer you'd expect.

Generally, you can work around these axis issues by finding alternative ways to express your query. For example, using the shorthand for the parent axis .. instead of parent::* does return the correct parent item – And you can construct alternatives for both these problematic axes this way. Alternatively, if you can express your code without the need for the query at all, you can find an ancestor item using the <a href="http://wonald.com/determine-sitecore-item-ancestors-and-descendants-without-xpath-or-traversing-the-content-tree-460.htm" target="_blank" rel="noopener noreferrer">Sitecore.Data.Item.Paths.LongID</a> property - a string containing all the ancestor IDs which you can process. (Though I should caveat this with the fact that I've not had a chance to try this approach myself yet)