SharePoint 2010

Here is a very handy PowerShell script that can speed up your web part development in SharePoint. It is a common scenario when you configure an OOB web part, and then you want to export it to XML  in order to integrate it in your custom solution for future deployments. This can occur in various scenarios, and with the arrival of the SharePoint 2013, it will become even more frequent. It works great in SharePoint 2010 also. I find it very helpful especially when working with search verticals, but it can be used in many other situations.

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue

function EnsureDirectory($exportFolderPath)
 if ( -not (Test-Path $exportFolderPath) ) {New-Item $exportFolderPath -Type Directory | Out-Null}

function ExportAllWebParts($siteUrl,$pageUrl,$exportFolderPath)
 $web = Get-SPWeb $siteUrl
 $wpm = $web.GetLimitedWebPartManager($pageUrl, [System.Web.UI.WebControls.WebParts.PersonalizationScope]::Shared)

EnsureDirectory $exportFolderPath

foreach($wp in $wpm.WebParts)
 $exportPath = $exportFolderPath + "\" + $wp.Title + ".xml"
 $xwTmp = new-object System.Xml.XmlTextWriter($exportPath,$null);
 $xwTmp.Formatting = 1;#Indent
 $wpm.ExportWebPart($wp, $xwTmp);

ExportAllWebParts $args[0] $args[1] $args[2]

# I use this script as a file, ExportWebParts.ps1. The required arguments for this script should be:
#The site absolute URL
#The page site-relative URL
#The folder path for export

#example usage ./ExportWebParts.ps1 Pages/default.aspx C:\temp\Export 

I have started a new project on CodePlex, a List Item Word Exporter for SharePoint. It offers the possibility to create templates based on Microsoft Word files, and associate them with lists. Using Edit Control Block you can then export any list item to a Word document, based on the predefined template.

Tasks List Example

The template for a Tasks list (left)
List item export based on this template (right)

In the template file, you can define tokens for item values, based on the list field display names, but there are also some built-in tokens for the current user, or the current date time.

Currently, the project only has a release for SharePoint 2013, but a release for SharePoint 2010 will also follow up.

Let me know what you think about it, and what improvements or suggestions you have for the next releases.

Feature stapling is an interesting concept in the SharePoint world, that allows you to associate a feature with any site definition. This feature will be activated automatically when a new site is created  from the associated site definition.

Feature stapling consists of two elements :

  • “Stapler” – the feature that specifies what features to be associated with site definitions

<Elements xmlns="">
<FeatureSiteTemplateAssociation Id="{Guid of the staplee feature}" TemplateName="SPSPERS#2" />
<FeatureSiteTemplateAssociation Id="{Guid of the another staplee feature}" TemplateName="SPSPERS#2" />

This example associates two features with the personal site definition in SharePoint 2013 ( in SharePoint 2010 the TemplateName would be SPSPERS#0 )

  • “Staplee” – the feature associated with a site definition or the feature that applies the customization

This feature can contain anything: a custom master page, list instances, custom pages, custom web parts etc.

The concept itself is fairly easy to use, but an important aspect in feature stapling is the order in which a site is provisioned [see reference about site provisioning order]

  1. global onet.xml
  2. Site-scoped features defined in onet.xml, in the order they are defined in the file.
  3. Site-scoped stapled features, activated asynchronously, on multiple threads
  4. Web-scoped features defined in onet.xml, in the order they are defined in the file.
  5. Web-scoped stapled features, activated asynchronously, on multiple threads
  6. List instances defined in onet.xml
  7. Modules defined in onet.xml

Because of this order of site provisioning, there are some scenarios which raise technical challenges:

  • Suppose your stapled feature depends on another stapled feature. Example – you would like to use publishing infrastructure on the site, and your staplee should be activated after the publishing infrastructure feature was activated.
  • The staplee uses list instances created in step 6.
  • The staplee creates sub-sites for this site definition.
  • The staplee modifies the home page – provisioned by a module in step 7

I have found different methods to deal with this:

1. Use a custom control that executes only once, and hence does all the changes after all the steps in site provisioning have been completed. The technique is explained in Steve Peschka’s blog post here. As a side-note on this, you don’t necessarily have to use a custom master page, you can always register a delegate control in the default master page. This works very well when you want to customize Personal Sites.

2. Wrap your changes in a Feature Event Receiver. You can decide not to execute the code right away (when the feature is activated), but to delay it until the site was provisioned (and all the steps are completed).

public override void FeatureActivated(SPFeatureReceiverProperties properties)
 var web = properties.Feature.Parent as SPWeb;
ThreadPool.QueueUserWorkItem(ApplyYourChanges, web.Url);

private void ApplyYourChanges(object state)
 var webUrl = state as string;
 var uri = new Uri(webUrl);

// additional conditions here -- perhaps check if a feature was activated
 while (!SPSite.Exists(uri))
 using (var site = new SPSite(webUrl))
 using (var web = site.OpenWeb())

//make your changes here


I prefer the second method, as it is cleaner, and doesn’t require a control that makes changes the first time the site is accessed.

Additional References:

Feature Stapling

Site Provisioning Order