Changing Web Part Properties When the Page is Unavailable

Applies To: SharePoint

The other day we made some changes that caused some issues with how one of our web parts was configured. Unfortunately, I hadn’t wrapped the problem in a try/catch and my error blew up the whole page. I’m sure I’m the only one that’s ever done that. So obviously I’ve got some code changes to make, but what do I do in the meantime? Fortunately, there’s some straight forward Powershell that lets you change web part settings (even custom properties like mine).

I found the solution to this over on Aarebrot.net where he was using the technique to change a web part that automatically redirected the user. I’ve just reproduced his code here and added some explanation and background.

When I first went to solve this problem I tried the ?contents=1 querystring trick to pull up the Web Part Administration page. If you’re looking for a quick solution you can add that query string to the end of your page’s URL and then delete the web part from the page and start over. But a more elegant solution is to just change the offending property using some easy Powershell.

Using the SharePoint 2010 Management Shell, run the following commands:

$web = Get-SPWeb "http://somedomain.com/sites/someweb"
$page = $web.GetFile("default.aspx")
$page.CheckOut()
$wpm = $web.GetLimitedWebPartManager("default.aspx",[System.Web.UI.WebControls.WebParts.PersonalizationScope]::Shared)
$part = $wpm.WebParts[0]
$part.SomeProperty = "The correct setting!"
$wpm.SaveChanges($part)
$page.CheckIn("Fixed that property")
$page.Publish("Fixed that property")
$web.Close()

What Just Happened?

In line 1 we’re just getting a reference to the web site (SPWeb) where your web part lives using Get-SPWeb. Just replace the URL shown with yours.

Lines 2-3 and 8-9 are only required if the page you’re modifying is on a publishing site or check in/out is required. Feel free to skip these (go directly to line 4) if you’re just editing a simple page. If your page does require check out to be edited, line 2 is simply retrieving the file (SPFile) using the GetFile method using the relative location of the page. Then line 3 calls the CheckOut method which, of course, checks out the file.

In line 4, we’re grabbing a reference to the Web Part Manager for the page (SPLimitedWebPartManager) using the GetLimitedWebPartManager method. Just replace the first parameter with the relative location of your page. The second parameter is the PersonalizationScope enumeration and can be User or Shared. You’re going to want to use Shared to affect everybody. The Web Part Manager object is what lets us get access to all the web parts on the page and screw with em.

In line 5, we grab the web part (WebPart) we want by index using the WebParts collection. In the example above I already knew that the web part I wanted was the first one in the collection. You can also pass the uniqueID property of the web part (instead of the index). You can find out both by simply calling the WebParts collection by itself ($web.WebParts) and everything will get listed to the screen.

To see all the available properties of the web part you can just type ($part) and it will list everything out including any custom properties. Then you can just set them like we do in line 6.

Line 7 uses the Web Part Manager’s SaveChanges method to incorporate all your changes. Lines 8-9 are again only required if your pages library requires check in/out and publishing. If it’s a simple page just skip to line 10. Line 8 uses the CheckIn method which takes a string for a check-in comment. Line 9 uses the Publish method which also takes a string for a comment.

Line 11 just calls the Close method and ensures we clean up all our resources.

That’s it! Now you can wrap that up in a script to loop through multiple pages and change properties on all sorts of web parts or just one-off fix those web parts you might have broken.

Refinement Panel Customization Saving Woes

Applies To: SharePoint 2010

Editing the Filter Category Definition of a Refinement Panel web part can make your search result pages so much better. This is one of the first things we customize and every time we do, I get tripped up by a really annoying setting in the web part.

Problem Scenario

I replace the XML in the Filter Category Definition property in the Refinement properties section of the web part. I hit Apply and everything validates. I save the page and run the results – No custom refinements! In fact, when I open the web part back up for editing, my custom Filter Category Definition is totally wiped out! Why isn’t it saving!?!?!?! Why am I weeping ever so softly?!?!! Why would I confess that on the internets?!?!?!?!

Solution

There’s a checkbox at the bottom of the Refinement properties section labeled, Use Default Configuration. This is checked by default. Unless you uncheck this when you place your custom XML in the property, it is going to completely ignore you and replace it with the default XML.

RefinementSettings

I can see why things work this way, but it is extremely unintuitive. It would seem that the web part should recognize there is custom XML in the Filter Category Definition and understand that’s what it should use. Then a button (NOT a checkbox) that says something along the lines of “Revert to Default Configuration” would be used to reset that XML when needed.

Oh well, nobody is asking my opinion anyway. So do yourself a favor and remember to uncheck that box whenever customizing the Filter Category Definition.

Broken Add New Document Links

Applies To: SharePoint 2010

We ran into an interesting problem the other day where a user called and said that everytime they clicked the Add New Document link they got a giant error message. I went to the site and was able to confirm that it was indeed blowing up.

This was only happening when the document library was being exposed through a web part on another page. Going directly to the library and clicking New Document or Upload Document in the ribbon worked just fine. The problem was obviously with the web part toolbar, which in this case was set to Summary Toolbar.

It appears this is something left over from our upgrade from SharePoint 2007 to SharePoint 2010. I would’ve thought the Visual Upgrade would have fixed this and it’s amazing no one noticed for well over a year! It seems that Microsoft changed not only the look of the link (switching the icon from a little square to a green plus and removing the word new) the underlying address also changed.

AddNewDocumentLink
Broken Old Style Link
NewDocumentLink
Correct Style Link

Taking a look at where these links were pointed, I could see that the old style link was pointed at listform.aspx:

/_Layouts/listform.aspx?PageType=8&ListId={LISTGUID}?RootFolder=

While the new style link was pointed at Upload.aspx:

/_layouts/Upload.aspx?List=LISTGUID&RootFolder

Fixing this is pretty easy. Just edit the web part and change the Toolbar Type to No Toolbar and click Apply:

ToolBarTypeNone

Then immediately switch the Toolbar Type back to Summary Toolbar and press OK:

ToolBarTypeSummary

Interestingly, other web parts sometimes show the old style link too (links, announcements, etc.) but since these all seem to still use the listform.aspx they continue to work. However, you can use the above technique to get them to match visually as well (green plus icon).

Hiding the List Item Selection Boxes

Applies to: SharePoint 2010

In SharePoint 2010 the standard listviewwebpart adds a checkbox to the left of each row. These only show up on hover and when you check the box the entire row is highlighted. You can check multiple boxes (or even use the helpful checkbox up top to select/unselect them all at once). This allows you to perform the same action on the selected item(s) using the ribbon.

SelectionBox MultiSelection

Generally, this is a good feature. However, not everybody agrees. If you’re doing some customization and you don’t want them to show up, you can do it through CSS. Although this is the technique I previously used, I ran across a post by Glyn Clough that made me face palm. I’ll leave the CSS technique in case it helps somebody and since I can think of at least one or two reasons you might want it (simple removal of all select boxes across an entire site or keeping the selection logic without the boxes) but if you want the simple answer just skip right to that solution.

CSS

If you’re deploying a branding solution or already using a custom style sheet just add the following:

.s4-itm-hover .s4-itm-cbx,
.ms-itmhover:hover .s4-itm-cbx,
.s4-itm-selected .s4-itm-cbx,
.ms-inlineEditLink .s4-itm-inlineedit,
.ms-itmhover:hover .s4-itm-inlineedit,
.s4-itm-hover .s4-itm-inlineedit,
.s4-itm-selected .s4-itm-inlineedit
{
    position: relative;
    top: 0;
    display:none;
    visibility:hidden;
    width:0px;
}

Bam! no more selection boxes! However, I’ve got no clue why you would want to hide those for an entire site. More likely you want to hide these from a specific list view or page. To do this you can slap a content editor web part on the page(Edit Page, Add a Web Part, Media and Content > Content Editor) and click inside it. Then choose the HTML drop down and pick Edit HTML Source:

EditHTMLSource

Then paste this inside there:

<style>
.s4-itm-hover .s4-itm-cbx,
.ms-itmhover:hover .s4-itm-cbx,
.s4-itm-selected .s4-itm-cbx,
.ms-inlineEditLink .s4-itm-inlineedit,
.ms-itmhover:hover .s4-itm-inlineedit,
.s4-itm-hover .s4-itm-inlineedit,
.s4-itm-selected .s4-itm-inlineedit {
    position: relative;
    top: 0;
    display:none;
    visibility:hidden;
    width:0px;
}
</style>

Save the page and you should see that all the list views on the page no longer have the selection box (although you can still click on the item(s) and get selection and multiselection):

NoSelectionBox MultiSelectionNoBox

So what about that Select All box up there? Why you want to break all the interfaces!?!

Unfortunately this isn’t as straight-forward. Microsoft did provide a convenient class for the checkbox: s4-selectAllCbx. However, until you hover over the web part, that class is not applied to the input control – Very strange. So applying some styles to that class will only take effect after someone has hovered over the part.

If you really want to do this with CSS you can add an additional selector to the above styles to get this (the key is that last selector .ms-vh-icon input):

<style>
.s4-itm-hover .s4-itm-cbx,
.ms-itmhover:hover .s4-itm-cbx,
.s4-itm-selected .s4-itm-cbx,
.ms-inlineEditLink .s4-itm-inlineedit,
.ms-itmhover:hover .s4-itm-inlineedit,
.s4-itm-hover .s4-itm-inlineedit,
.s4-itm-selected .s4-itm-inlineedit,
.ms-vh-icon input {
    position: relative;
    top: 0;
    display:none;
    visibility:hidden;
    width:0px;
}</style>

This hides them all but doesn’t shrink the column. There’s probably a CSS way to do that too, but honestly let’s just use the setting below.

The Real Solution

So everything above has been overkill. I remember looking for a simple setting to turn those boxes off and not finding it. I can’t be the only one since you’re reading this article – but it doesn’t get much easier than this.

Just edit the view (either the view used by the web part or an actual view on the list) and scroll down to the Tabular View section and uncheck the box next to Allow individual item checkboxes:

FacePalm

Click OK and now those checkboxes are removed! Unfortunately so is all selection and multi-selection. So if you have some strange need to keep the selection but remove the boxes, see the CSS solution above. If you just wanted to remove them altogether, remember to always look at the settings!

If you take a look at the XML generated for the view you’ll see that all this is doing is adding a TabularView attribute to your View element and setting it to FALSE.

InfoPath List Form New Item is Read Only

Applies To: SharePoint 2010, InfoPath 2010

Many of you are probably aware that you can replace the standard list item forms with InfoPath browser based forms (SharePoint 2010 Server Enterprise only), and if you weren’t, you are now. It’s as simple as hitting the Customize Form button on the List tab of the List Tools ribbon:

By default the same form is used for all three views (New, Edit, & Display). You can create new views in InfoPath (Page Design tab -> New View) and then back in SharePoint use the Form Web Parts dropdown shown above to customize the InfoPath Form Web Part to show the view you want. There are other guides out there to getting this done that go into more detail, but that’s the gist of it.

I ran into an interesting problem the other day when using this feature. I had a form view for New, Edit & Display and everything was working great. Then I realized that I had some optional fields that I didn’t want to show on the display form if they were blank.

So I wrapped those up in a section and slapped a formatting rule to “Hide this control”:

Boom! I published the form and everything displayed as expected. I did a bunch of other stuff and then went back to add another item to the list. Suddenly the form view I was using for the New List Item was completely Read-only. Obviously, that’s a problem.

I opened the form back up in InfoPath and made sure the View Properties didn’t have the Read-only checkbox checked – Nope. I cried a little but then through the blur of my tears I noticed that every field on every view that wasn’t in one of my auto hide sections had a little blue info icon. Hovering over the icon showed FieldName (Control bound to missing field or group). What a heck?

Meanwhile the Edit form is still working great. So I right-clicked on the fields choose Change Binding and verified they were all hooked up correctly. Some searching brought me to this TechNet thread. The answer is in there but it wasn’t super obvious to me.

Basically, by adding the sections I had caused all the other fields on all the views to be outside the SharePointListItems_RW section and this breaks their binding. So how do you fix it? It’s actually pretty simple.

Right-click on any of your Optional Sections and choose Section Properties from the context menu. In the Default settings section of the Data tab is a radio button. Switch it from Do not include the section in the form by default to Include the section in the form by default. Click OK.

Suddenly all the little blue info icons go away and every Optional Section is now called Section. Re-Publish your form and you’ll find the auto-hiding still works perfectly and your New Item form is no longer Read-only. See? It can’t rain all the time sunshine!

Open a Link in SharePoint 2010’s Modal Dialog

Applies To: SharePoint 2010

Recently I’ve been customizing the XSLT of some of my XsltListViewWebParts. Getting all of that to work is worth another post in itself, but I wanted to talk briefly about a small frustration I had. I was customizing an announcement’s list part and I stripped out most of the nearly 1700 lines of XSLT used by default. However, one of the things I liked was being able to open the announcement in the modal dialog (sometimes called the Lightbox or the popup window):

Some searching through the autogenerated XSL for my view, I came across this section in the LinkTitleNoMenu.LinkTitle template:

<a onfocus="OnLink(this)" href="{$FORM_DISPLAY}&amp;ID={$ID}&amp;ContentTypeID={$thisNode/@ContentTypeId}" onclick="EditLink2(this,{$ViewCounter});return false;" target="_self">
	<xsl:call-template name="LinkTitleValue.LinkTitle">
		<xsl:with-param name="thisNode" select="$thisNode"/>
		<xsl:with-param name="ShowAccessibleIcon" select="$ShowAccessibleIcon"/>
	</xsl:call-template>
</a>

I’m going to dissect what’s happening in terms of XSL for the next couple of paragraphs. If you’re just looking for the format needed, skip to the Link Format section.

Basically this is the link that gets generated inside the view’s table. The call-template element is used to fill the contents (link text), but I already had that covered and am mostly just interested in the formatting of the link to do the modal dialog magic.

Some quick experimentation shows that the onfocus call was not needed for the popup (This is what causes the menu to display and the box around the row in a standard view). Also not needed is the target=”_self” since this is equivalent to leaving the target attribute out entirely. There are really just 2 key items:

HREF

This is the URL to display in the modal dialog. In this case, it’s generated using a number of variables defined automatically. The $FORM_DISPLAY is the absolute path to the item display page. The $ID is generated using a simple Template call (we’ll come back to this). and the $thisNode/@ContentTypeId is pulling the ContentTypeId attribute from the current Row element in the $AllRows variable populated by the dsQueryResponse XML. For now, all you need to know is that it is automatically finding the display form URL and populating the necessary ID and ContentTypeId query strings for the specific item URL.

OnClick

This calls the EditLink2 javascript method defined in Core.js. This extracts the link with the webpart’s ID ($ViewCounter) and shows it in the modal dialog. Then it returns false to prevent the browser from following the link like normal.

Trying to implement this exactly in my code wasn’t too hard. Unfortunately, it wouldn’t load in the popup and always just opened the page directly. Doing some searching, I came across a quick explanation and solution on technet. The EditLink2 function attempts to use a window object referenced by my webpart’s id ($ViewCounter). Whatever code sets this all up wasn’t firing in my XSL causing the window reference to be NULL and making the function default to just opening the link. Instead of tracking it down somewhere in the default generation, I did something similar to the proposed solution on technet.

Link Format

Ultimately my goal was to have a link generated using this format:

<a href="http://mysharepoint.com/sites/thesite/_layouts/listform.aspx?PageType=4&amp;ListId={SomeGUID}&amp;ID=SomeID&amp;ContentTypeID=SomeContentTypeID" onclick="ShowPopupDialog(GetGotoLinkUrl(this));return false;">Click Me</a>

So, I’m using the same link generation (but this could be any link). The real difference is that instead of calling EditLink2 I’m calling ShowPopupDialog. For the URL, I’m using a technique found in the EditLink2 method of calling GetGotoLinkUrl which extracts the URL from the link element.

XSL Implementation

To get this to work in XSL, you can do something similar to this:

<xsl:for-each select="$AllRows">
	<xsl:variable name="thisNode" select="."/>
	<xsl:variable name="link">
		<xsl:value-of select="$FORM_DISPLAY" />
		<xsl:text>&amp;ID=</xsl:text>
		<xsl:call-template name="ResolveId">
			<xsl:with-param name="thisNode" select ="$thisNode"/>
		</xsl:call-template>
		<xsl:text>&amp;ContentTypeID=</xsl:text>
		<xsl:value-of select="$thisNode/@ContentTypeId"/>
	</xsl:variable>

	<a onclick="ShowPopupDialog(GetGotoLinkUrl(this));return false;">
		<xsl:attribute name="href">
			<xsl:value-of select="$link"/>
		</xsl:attribute>
		<xsl:text>View Announcement</xsl:text>
	</a>
</xsl:for-each>

In the above XSL, we’re looping through each row returned by your view’s CAML query. We setup a link variable that builds the full HREF attribute in lines 3-11. The thing to note is the call to the ResolveId template to pull the item’s ID from the row. This is a standard template that will automatically be referenced as long as you keep the standard includes (main.xsl and internal.xsl).

Then we generate the actual html link in lines 13-17 using the $link variable we created above. This could be consolidated some, but hopefully it’s relatively easy to follow in this format.

That’s it! Now you can generate those links using XSL or follow the link format to make them on your own (like in a content editor web part).

Using Feed Parameters in the RSS Viewer Web Part

Applies To: SharePoint 2010, RSS Viewer Web Part

The RSS Viewer web part is an Out of the Box SharePoint web part that can really add to your site by allowing you to integrate dynamic content directly on your pages from other sites in your environment (requires either anonymous or kerberos authentication) or from sites all over the web. You can add it like any other web part (Located under Content Rollup) and get it going quickly by setting the Feed URL property.

There are feeds all over the web and getting the URL for these is generally straight forward (click the RSS icon/button and then copy the URL) and I’ll let you figure that part out. If you’re simply grabbing a news feed from Yahoo! or someplace, then you’re probably done. There’s a lot that can be done with the formatting of the feed’s content using XSLT, but that’s out of scope for this particular article.

However, what if you would like something a little bit more dynamic? Some feeds are very customizable using query string parameters to automatically filter what you want. A good example might be pulling the SEC Filings from the Securities and Exchange Commission website. You can get a feed of Google’s Filings using the following URL:

http://www.sec.gov/cgi-bin/browse-edgar?action=getcompany&CIK=0001288776&type=&dateb=&owner=exclude&start=0&count=40&output=atom

There are several parts to this URL beyond the base of http://www.sec.gov/cgi-bin/browse=edgar (They begin after the ? mark and are separated by the & and take the format of name=value). The one I’m most interested in is the CIK (Central Index Key). This is what tells the feed to return Google’s filings. (As a bonus, for publicly traded companies you can replace that 10 digit number with their Ticker Symbol: GOOG for Google).

Great! Now you can generate a feed for multiple companies’ SEC filings using multiple RSS Viewer web parts. But what if you only want one web part that can switch which company is being displayed? That’s exactly where Feed Parameters come in.

Configure the Filter

Like many web parts, the RSS Viewer web part allows connections to other parts including the filter web parts. Most any of the Filter parts will work depending on what you’re trying to accomplish. An obvious example would be to use the SharePoint List Filter web part to pull company ticker symbols in from another SharePoint list and use a drop down to select which filings to view. My preference, however, is to use a Query String (URL) Filter part so that I can hook it to multiple parts to create a dynamic page that can be linked as if it were many pages. I’ll show you how to hook that up, but the basic concept is the same for any of the parts – Filter some value and send it to the RSS Viewer.

Add a Query String (URL) Fitler part to your page (Located under Filters):

From the tool pane for the Query String (URL) Filter part the key values can be found in the Filter section. The Filter Name property should match the query string property name in your RSS Feed’s URL. So in this case our Filter Name is CIK. The Query String Parameter Name is the name of your own query string to the page. In this case I’ve set it to Symbol. The Default Value is optional, but is generally a good idea so that if the page is accessed without a query string, the feed still shows something. I’ve set ours to GOOG (Although I could easily have set it to Google’s CIK value since the SEC feed is pretty flexible):

It’s also a good idea to also give your filter web part a better name than the default since this is the name you’ll see when setting up the connection. This is just the Title property in the Appearance section. I’ve set mine to Symbol Filter. Press OK to save your changes.

Setup the Connection

Using the drop down menu for the RSS Viewer Web Part choose Connections > Get Feed URL From > Symbol Filter (If you don’t have a Connections menu, select Edit Web Part and look again):

If everything has been successfully connected the Query String (URL) Filter should look similar to this when editing the page (it isn’t visible normally):

If you add ?Symbol=MSFT to the end of your page’s URL (If your page is http://app/site/SitePages/Home.aspx then the filtered url would be http://app/site/SitePages/Home.aspx?Symbol=MSFT) then the RSS Viewer should now be showing Microsoft’s latest SEC Filings. Just kidding! There’s one little gotcha that’s very easy to fix.

If a feed parameter is already set in the RSS Viewer’s URL, then any feed parameters from connected web parts are ignored. In this case, this is because we pasted the sec.gov feed’s URL in directly including the CIK=0001288776 section of the URL. To fix this, just delete this part of the URL. So our new feed URL will look like:

http://www.sec.gov/cgi-bin/browse-edgar?action=getcompany&type=&dateb=&owner=exclude&start=0&count=40&output=atom

Now try that filtered URL (Your page + ?Symbol=MSFT) again and you should see Microsoft’s SEC Filings:

This quickly gives us a lot of flexibility. This works great for all sorts of feeds allowing you to filter or customize your feeds before they ever get to you; and all on the fly.

Conclusion

So here’s the summary of what you need to do to get this working:

  • Add an RSS Viewer web part and set the Feed URL to the address of the feed you want to pull. Remove the dynamic parameter you want to set.
  • Add a Filter web part and configure it to pass the filter name as the name of the dynamic filter in the feed URL
  • Connect the RSS Viewer web part to the Filter web part using the Feed Parameter connection
  • Shout Abracadabra every time anyone uses a dynamic view of the page

The RSS Viewer part can be a very powerful part of your page allowing dynamic content without any custom code.