Update 28/07/2011: This post is now part of a series consisting of several other bugs I’ve seen with the XSLT List View Web Part:
- View settings lost on saved XSLT List View Web Part
- Content type enabled list XLV can’t be added to sites
- XSL Link Property and the ECB Menu (this post!)
- Multiple web front ends, conflicts and the XLV
- Unable to use folders with cross-site XLV
I’ve recently blogged about altering the presentation of a SharePoint 2010 XSLT List View Web Part (XLV) using a technique called XSL Template Override. After seeing that this this was an option, and loving the control and flexibility it gave, it started to be used widely on my currently project. Imagine my face then when I found a bug with the approach :S
I noticed this bug a while ago, and it was also seen by others on my team and even by a commenter on my blog (thanks @Mikael) – however it’s not been until today that I’ve dug a little deeper to see what was causing the problem.
The problem isn’t obvious at first when you’ve set up your custom XSL and linked it to your XLV. It’s more than likely that you’ll see the results that you’re after – in terms of presentation. However, the issue I’ve then had is when trying to interact with items in the list through the ECB Menu on an item. (This is the menu that appears when clicking the arrow – usually on the title field).
When trying to edit an item I get the following error message that the item may have been deleted!
The option to edit an item from the ribbon is also unavailable. Strangely though this doesn’t seem to affect all of the list functionality – for instance it’s still possible to add a new item.
After some experimenting and digging around I realised that this only seemed to be a problem when using the XSL Link property, i.e. not just embedding the custom XSL into the XSL property of a web part (which is what happens by default when you, say apply conditional formatting in SharePoint Designer). What’s more, it only seems to be an issue if the XSL stylesheet that you’re linking to is in the content database, i.e. in a library on the site. By putting the XSL stylesheet on the file system in the LAYOUTS folder the problem goes away!
The Root Cause
Thankfully Stuart Starrs (@starznet) happened to be sitting just across the way and so he was able to work his magic to help me look into this further! By using Reflector to step through the SharePoint code he was able to trace this down to the fact that (for some reason!) an error is being thrown when trying to resolve the URL of the XSL stylesheet in a library.
Obviously the XSL file is being used – and therefore your XSL Link property is valid – because you can see the changes you’ve made to the presentation of the XLV. However, there seems to be a genuine bug when it tries to use this URL internally.
We’ll continue to look into this, but in the meantime the good news is that there are several workarounds available…
The first and obvious workaround is to not use the XSL Link property at all. I see that this can be done in two ways:
- Either edit the page in SharePoint Designer and the XSL will be embedded directly into the web part
- Or, if SPD is not available/ viable, export the web part (using this technique) and then manually edit the .webpart file to include the XSL in the XSL property
The other workaround is to deploy your XSL to the LAYOUTS folder and then link to that. That seems to me a nice robust solution – however it has to be contrasted to the amazing flexibility that is just tantalisingly out of reach by storing the XSL in a library on the site.
I hope to continue looking into this issue and will post again if I discover anything more. It’s good to know however that there are workarounds available – and, in fact, this may not even be an issue for you if you don’t need to use the ECB or ribbon!