XLV Bug: View settings lost on saved XSLT List View Web Part

After working with the XSLT List View Web Part for a good while now I’ve discovered some great features and a few annoying niggles or bugs. Whilst I’ll continue to post new finds and interesting techniques, I thought it worthwhile gathering the list of bugs together into a series – as I believe they’re something you should be aware of if planning on using the XLV extensively in your solution (and why wouldn’t you!).

The series will consist of:

The Bug

Having configured your list view exactly how you need; possibly having spent a while adding/ removing columns, choosing sort orders and filters etc you now decide that you want to re-use all your effort by having exactly the same XLV on a different page, or even site.

The first step is to export your web part. This can be done via SharePoint Designer 2010 or by the XLV export/ import method that I’ve previously posted. You now try and add your web part to a page using the browser, i.e. not using SharePoint Designer.

Immediately after adding the web part everything is looking great – the list view is displayed exactly as it was on wherever you exported it from. Now you hit Save or Check In… and the XLV reverts to the default view on the list! Your carefully configured view has just been lost – and that’s the bug 🙂


Here’s an example of this in action. First I add a simple custom list to a page, modify the view and, just because we can, jump into SPD 2010 to add some custom formatting:
Customised XLV

I now use SharePoint Designer to export the web part and add it to the gallery:
Export web part option in SPD2010

Now, I go back to the browser, create a new page and add the web part. There’s my nicely configured view…
Added XLV with correct view in edit mode

But now I hit save on the page and BOOM there goes my view back to the default on the list:
XLV reverting to default view

So my view has been changed, including my sort order and columns chosen to display – but strangely my custom formatting is still there! What is going on…


I lack the skills to step through the underlying code of what exactly happens when the imported web part is attempted to be saved back to the page – however I think we can infer a few things from the behaviour and by inspecting the web part properties (of an exported XLV).

Firstly – why is the custom formatting still there, plus the web part title, chrome settings etc etc. Well I think we can confidentially assume that those particular properties of the web part are persisting. Looking at the .webpart file of an XLV we can find the corresponding properties and their values.

So where are the view settings defined in the properties. Well, I can only assume that this is in the property called XmlDefinition. Looking at this property we can see that it defines the CAML necessary for the view – plus it seems to reference an actual view on the list itself…

I found this excellent post by Stefan Stanev who goes into a great amount of detail explaining that when you add a list view web part to a page there is actually a view created on the list itself! The view is set to hidden and so you never know it’s there – but it’s fascinating that it exists.

Now we think we know that the XmlDefinition property is where an XLV gets its view settings from we should be able to use this to give an XLV a particular view which can be imported again and again right? Well, you’d think so… but unfortunately I haven’t been able to get it to work yet.

It feels like I’m tantalising close to working this out – but then hey, why should I have to? I can add an exported XLV into the gallery using a supported tool like SPD. When adding to a page this then appears to take on the view settings, only to have them lost on saving a page. That sounds like a bug to me!


The (only slightly) good news is that you can use SharePoint Designer to add a web part to the page and it will remember the view settings! Obviously there is something going on behind the scenes different to what happens when adding through the browser.

Another option is to set the default view on the list to be the same as your web part view – and then this will be the view used when adding the web part.

[This was done on SP2010 RMT – I haven’t looked at SP1 yet]

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

11 comments to XLV Bug: View settings lost on saved XSLT List View Web Part

  • Fernando

    Hello!!, thanks for posting this information, i’m having the same problem, when trying to import an XsltListViewWebpart using javascript, do you know if this has been fixed?

    thank you 🙂


    • Hi Fernando – I don’t think this has been fixed; and the more I work with the XLV the more I think it never will be! This is because of the way that whenever you add a new XLV to a page it actually creates a new hidden view on the list. Stefan has a great post about this if you’re interested in the details.


  • Fernando

    Hello, I’m trying to import the XsltListViewWebpart using javascript, then i’ll try to change the XMLDefinition property using ECMA Script to customize the fields i want to show, if this works i’ll let you know 🙂

  • Daniel


    I modified the default style as generated by SharePoint and it appears great in designer. Save to Gallery and import in my test web part page – all looks good. I check in the page in via designer. When I refresh the page in the browser; it unfortunately it still shows SharePoint’s boring old style. Ahhhhh … This kind of leaves a couple of choices. Recreate in style in /_layouts/xsl or recreate with a DVWP.


    • Hi – the style should remain after importing a web part – however the view will be reset to the default. So therefore you might not see exactly what you were expecting, e.g. if you’ve styled the ‘status’ column but the status column isn’t in the view… Where the XSL lives isn’t going to affect this unfortunately.

      Reconfiguring the view through the browser is the only (non-code) option I’ve come across I’m afraid.


  • Michael

    I have used days to try to solve this. XsltListViewWebPart would be very powerfull thing in SharePoint if we could reuse it properly. It is definitely a bug or utterly idiotic design from MS. The only way I have been able to reuse XsltListViewWebPart is with the help of Visual WebPart.
    Use SPD to set your wp. Do not export it to file or gallery, but switch from design|split|code to the code view. If you had highlighted the wp the selection needed to copy is already highlighted, copy to clipboard.
    In Visual Studio create a new Visual Web Part. In the .ascx after the initial stuff paste stuff. Rename the ID of your web part you just copied to something more familiar. Then in the codebehind of visual web part set
    WebId, ListId, ListName, ViewGuid.
    You need to set also ToolbarControl if your list is in another site.
    But this method has disadvantages ofc. You do not get the ribbon icons and toolbar for the list/lib when selecting rows. You can not change view settings in web part’s config as this is now a visual web part.

  • Jarno


    If you export your site as template and open up the web part file, you can find that even SharePoint itself exports the XsltListViewWebPart as a BinarySerializedWebPart element in a feature. The interesting parts are:

    – This gets deserialized correctly, when creating a new site based on the template. I.e. the view settings ARE retained in this case.

    – When I tried to copy/paste that same BinarySerializedWebPart element into a custom feature, so that I could deploy the view settings, the view settings were NOT retained. I suppose I wasn’t copying everything I needed, or some minor modification screwed it up. Or then there’s something more going on..

    I’m currently working on a sandboxed solution and the most annoying thing of course is that you can’t even provision XsltListViewWebParts through code in a sandboxed environment, so things really get tricky their, if you want to include them in your templates. Looks like Save Site as Template is the way to go in the sandbox.

  • @Michael, @Jarno – thanks for for the additional info, very interesting.

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>