XLV Bug: XSL Link Property and the ECB Menu

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:

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 Symptom

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!

XLV Bug Item No Longer Available

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!

share and enjoy
  • Print
  • Twitter
  • Digg
  • del.icio.us
  • StumbleUpon
  • Yahoo! Buzz
  • Google Bookmarks
  • Facebook

17 comments to XLV Bug: XSL Link Property and the ECB Menu

  • […] approach that can cause the ECB menu and ribbon not to function correctly. I've written this up here] share and enjoy SharePoint 2010   Lists, SharePoint Designer 2010, XLV, XSL   […]

  • Glyn, thanks for posting this update. Your overriding technique is very interesting, but there would be real benefits from managing the xslt files centrally, in a document library.
    Just a thought: did you try relative vs absolute path for the link?

  • ernst


    Thanks for your posts about the XSLT List View Web Part. It really helped me getting to grips with some of the ‘challenges’ of SharePoint.

    Thank you! Keep up the good work (and posts) 😉

  • SPFan

    Hello Glyn,

    have you started debugging the javascript to know what is going on ?

    I wanted to start this but if you did it …


    • Hi,

      I haven’t looked into this for a while – though from what I remember then it wasn’t an issue with the JavaScript, more with how the web part loads the XSL; and it not correctly resolving the URL of the stylesheet.

      If you’re going to take a look into this further it would be great if you could post an update if you make any progress on this!


  • SPFan

    I will and I’ll keep you posted if I find anything interesting

  • SPFan

    Indeed there is nothing wrong with the javascript.

    for info and I think I do not bring anything new with this.

    This is the method which blows up


    • Thanks for looking into this some more. I think that method is the one that Stuart Starrs helped me look at with Reflector – and it does come down to (something as silly as) not being able to resolve the URL correctly. Maybe this will/ has been fixed in one of the CUs…

  • SPFan

    Hello Glyn,

    I have asked directly on the SharePoint forum and I got an answer from a Microsoft guy.

    here it is : http://social.msdn.microsoft.com/Forums/en/sharepoint2010general/thread/c7f07596-cb45-49fe-ba0f-88faa5fb981d

    we might need to wait a bit longer to get a fix.

  • spevilgenius

    There is another workaround that might help here. You can still host your files in the database but use the XSL property to create a simple XSL stylesheet. In this stylesheet, use the xsl:import option to import the file from your library. I have done this and it does work.

  • Hi,

    I know this is quite old, but it is relevant to me and was somewhat helpful. Unfortunately, the xsl:import trick mentioned by spevilgenius did not work for me. I also tried with xsl:include but no dice. In debugging the javascript, I discovered that the problem is a result of the /_layouts/inplview.aspx failing to display a web part. Evidently how this works is there is an ajax GET call on the click handler whose returned output is used to create the ECB menu. When the XSLT is inline, this works. When it is linked in the content DB, it doesn’t. A URL such as this one…

    http://myhost/mysite/_layouts/inplview.aspx?Cmd=Ctx&List={List GUID}&View={View GUID}&ViewCount=0&IsXslView=TRUE&Field=LinkFilename&ID=[Item ID]&ListViewPageUrl=[URL of the page]

    …outputs “Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer… etc”. The javascript code, which is in the FetchEcbInfo() function in core.js (or core.debug.js) is unable to find what it’s looking for and returns.

    So it appears that the page is unable to give inplview.aspx the reference to the XSLT used by that web part or by something else. It is a rather clunky way of doing it if you ask me. It’s also puzzling because nothing used to create the ECB is overridden in the external stylesheet as far as I can tell. I’ll start commenting templates and see whether I’m wrong about that.

  • I’ve find what is probably the best workaround. This post here gave me the clue: http://gustavofrederico.blogspot.co.uk/2011/11/my-daily-sharepoint-frustration-xx.html

    If you edit the web part and under Ajax Options make sure that “Enable Asynchronous Load” is ticked, you can use XslLink with a stylesheet in the content database. The code that made the bad ajax call is avoided as the ECB menu is loaded in a different way.

  • I just wanted to post an update on this I had a need to use this again but needed it in a Visual Studio solution for a list definition. I wanted to use a site relative xsl file in a document library and still make the list definition work. I have never been able to just tell the XslLink property to use a relative path. My thought was that I can provision a custom file to a library easy enough, but I also have to be able to point the XslLink to it. So in a moment of zen thinking (or evil in my case!) I decided to try to provision 2 xsl files. I deployed one to the SiteAssets library in a folder called xsl. This is the one that has my customizations (overrides) in it. The other is deployed to the Layouts/XSL folder of the hive. That file just uses 3 xsl:import tags. The first 2 are the main.xsl file and the internal.xsl file. Then I point the 3 import to the file in the SiteAssets library. This xsl file is what is used for the XslLink property as it is provisioned to the spot where SharePoint expects them to be but I can still use my custom rendering from a file in the document library.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>