Another instalment of my mini-series about some bugs that I’ve encountered with the XSLT List View Web Part – this time looking at an error that occurs if you try and show a content type enabled list on a different site using the XLV.
This post is 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 (this post!)
- XSL Link Property and the ECB Menu
- Multiple web front ends, conflicts and the XLV
- Unable to use folders with cross-site XLV
I’ve previously posted on how it’s possible to display the XLV on a different site to the original list without the need to resort to SharePoint Designer. This is a nice solution for a really really useful web part, especially when combined with easily added custom XSL in the XLV. However, I’ve run into a problem with this when the list I’m trying to display has content types enabled!
—-
Update 03/10/11: This issue has been corrected in the August 2011 Cumulative Update! I have been able to add an XLV for a list on a different site. Note – when adding an XLV to a publishing page I had a few ‘list does not exist‘ errors which for a while prevent me viewing the page. By editing and immediately saving the XLV before saving the page I was able to bypass these errors.
—-
As I’m sure you’re all aware (but just to be completely clear!) content types can be enabled on a list by navigating to List Settings > Advanced Settings and selecting allow management of content types. If your solutions are anything like mine then I’d bet that content types are (rightly) used on the majority of your lists.
The Bug
I have seen no issues when enabling content types and using the XLV on the same site as where the list resides – even when customising the XSL or using web part connections etc. The issue occurs when exporting an XLV (perhaps through SPD or perhaps manually) to the web part gallery and then choosing to add this web part to a new site. The error received at this point is pretty hard to miss! And in fact I’ve found no satisfactory way to get past this without going into the web part maintenance page and completely deleting the web part (without resorting to custom code).
Example
Here’s an example of this in action. I simply create a new out of the box Tasks list – which by default has content types enabled on it. I then add an XLV to a page in the same site for this new list.
Next, after exporting the web part through SharePoint Designer 2010 and adding it to the web part gallery (making sure to reference the same list, not a relative list) I then go to a different site and try to add the web part. That’s when I see the error above!
How do I know that this is related to content types? Well, simply go back to the list and disable the allow management of content types option and refresh the page where you’ve tried to add the web part. You’ll now notice that the web part displays! (And it displays using the default view of the list, not the one saved in the web part as per another bug I mention in this series)
Obviously by disabling content types we’ve completely altered the functionality of the list and so this isn’t a viable solution – however it is a great diagnostic aid in pointing out where the root cause of the issue may lie.
Explanation
This is a long term issue on our current project and one that has appeared in various guises over the last 6 months or more. A colleague, Stuart Starrs, did some digging around and actually wrote a web part as a potential workaround for the issue. You can find a detailed post with source code on his blog.
It appears that the trouble lies with the code which is creating the ‘toolbar’ for the XLV, as you can see from the below error taken from the ULS logs:
System.ArgumentException: Value does not fall within the expected range. at Microsoft.SharePoint.SPWeb.GetWebRelativeUrlFromUrl(String strUrl, Boolean includeQueryString, Boolean canonicalizeUrl) at Microsoft.SharePoint.SPWeb.GetFolder(String strUrl) at Microsoft.SharePoint.WebControls.NewMenu.AddMenuItems() at Microsoft.SharePoint.WebControls.ToolBarMenuButton.CreateChildControls() at Microsoft.SharePoint.WebControls.NewMenu.CreateChildControls() at System.Web.UI.Control.EnsureChildControls() at Microsoft.SharePoint.WebControls.TemplateBasedControl.OnLoad(EventArgs e) at Microsoft.SharePoint.WebControls.ToolBarMenuButton.OnLoad(EventArgs e) at System.Web.UI.Control.LoadRecursive() at System.Web.UI.Control.LoadRecursive() at System.Web.UI.Control.LoadRecursive() at System.Web.UI.Control.LoadRecursive() at System.Web.UI.Control.LoadRecursive() at System.Web.UI.Control.AddedControl(Control control, Int32 index) at Microsoft.SharePoint.WebPartPages.DataFormWebPart.CreateChildControls() at Microsoft.SharePoint.WebPartPages.BaseXsltListWebPart.CreateChildControls() at Microsoft.SharePoint.WebPartPages.WebPartMobileAdapter.CreateChildControls() at System.Web.UI.Control.EnsureChildControls() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
Workarounds
As this is such a fundamental issue it’s a very tricky one to say what a suitable workaround is. Other than not using content types on list (!!!) the custom web part from Stuart is definitely the only way we’ve found so far. However, I have been chasing this up with Microsoft and they have recognised it as a bug – and there are hopes that at some point a fix will make it into a cumulative update.