Using PowerShell to Set List View Parameters in SharePoint Web Parts

While working on some modifications to the SharePoint 2010 blog site template I ran across an interesting problem. I was trying to duplicate the functionality of a particular web part; in this case, the Posts web part which outputs a formatted display of list items on the Category.aspx page of a blog site. The default web part was listed in the contents page (reachable using the "?contents=1" query string parameter) as a basic XsltListViewWebPart, which meant that I should be able to drop the Posts web part from Lists and Libraries in the web part gallery, set the view, and get the desired results. If only it were that simple.

No matter which view I picked, all the web part showed was a standard list view with rows and columns, not the nicely formatted view with the calendar page image, title link and summary information that I was after. Since it was a stock list view web part I knew it was using a view to fetch the data and then transforming it in XSL but there didn’t seem to be any way to force it into using the correct view. Assuming that the view itself might be hidden from the drop-down selector, I turned to PowerShell to see if I could find out what was going on. I began by iterating through the web parts on the page to find the one I wanted and writing out the view ID:

$site = new-object Microsoft.SharePoint.SPSite("http://www.binarywave.com/blogs/eshupps")

$web = $site.openweb()

$webpartmanager = $web.GetLimitedWebPartManager("http://www.binarywave.com/blogs/eshupps/Lists/Categories/Category.aspx",
[System.Web.UI.WebControls.WebParts.PersonalizationScope]::Shared)

for($i=0; $i -lt $webpartmanager.WebParts.Count; $i++) { if($webpartmanager.WebParts[$i].Title -eq "Posts")
{ write-host $webpartmanager.WebParts[$i].ViewId } }

The value I got in return was "8". Well, ok, that didn’t tell me much, so I had a look at the schema.xml file for the Posts list in the Blog site template (located at \14\template\sitetemplates\blog\lists\posts\schema.xml). I found the <View> node with a BaseViewID value of "8" and compared it to another node with a BaseViewID value of "1". Aha! The "1" view refers to AllItems.aspx and contains a DisplayName property along with a URL value whereas "8", like a few others in the same schema, has no such information. Clearly, these are hidden from the View selector of the web part properties, which is why I was unable to pick the correct view in the UI. Now the only question was, could I set the view (and any other web part parameters I desired) programmatically? A few changes to the PowerShell script applied to the out-of-the-box list view web part achieved the desired result:

$site = new-object Microsoft.SharePoint.SPSite("http://www.binarywave.com/blogs/eshupps")

$web = $site.openweb()

$webpartmanager = $web.GetLimitedWebPartManager("http://www.binarywave.com/blogs/eshupps/Development/Development.aspx",
[System.Web.UI.WebControls.WebParts.PersonalizationScope]::Shared)

for($i=0; $i -lt $webpartmanager.WebParts.Count; $i++) { if($webpartmanager.WebParts[$i].Title -eq "Posts")
{ $wp = $webpartmanager.WebParts[$i]; $wp.ViewGuid="{1E720D19-01A0-4B90-A14B-73CFC85092F8}"; $wp.ViewId=8;
$wp.ChromeType="None"; $webpartmanager.SaveChanges($wp); } }

Now the web part shows the proper view even though it’s hidden from the UI. Although this particular example applies to artifacts in the Blog site template, I’m pretty sure the same mechanism is being used elsewhere, with "hidden" views specified in the list schema. In this case I used PowerShell to solve the problem but could have just as easily written a console application (or application page, for that matter) to do the same thing. Either way, if the list view you want doesn’t show up in the selector, a bit of simple code similar to that shown above will fix it right up.