Waldek Mastykarz

Inconvenient provisioning Web Parts to Wiki Pages in Sandboxed Solutions

Waldek Mastykarz — Sun, 05 Feb 2012 14:10:48 +0000

Sandboxed Solutions are a powerful way to create SharePoint 2010 Solutions in a secure manner. The price of security however is limited access to the SharePoint API which makes it challenging to accomplish certain tasks like provisioning Web Parts to Wiki Pages. Find out how to provision Web Parts to Wiki Pages in Sandboxed Solutions.

Playing in the Sandbox

The introduction of Sandbox in SharePoint 2010 empowers both IT-Pros and Developers. Using Sandboxed Solutions developers can deliver rich solutions that leverage the SharePoint 2010 capabilities. Because those solutions are executed in an isolated fashion and have limited access to the SharePoint API and the .NET Framework, there are less risks involved with deploying and using them in a SharePoint Farm. One more important benefit of using Sandboxed Solutions is, that they require less involvement from IT departments as they can be deployed and managed by Site Collection Administrators.

In SharePoint 2007, where no Sandbox was available, designing SharePoint Solutions was a lot like all or nothing: either developers were allowed to create solutions with custom code and had virtually access to the full SharePoint API and .NET Framework or SharePoint Farms were sealed, no custom code would be allowed and developers were tasked with the challenge to get things to work using nothing more than the standard functionality of the SharePoint platform. As you can imagine neither of those two approaches is perfect. Allowing developers to use the full API means you have to spend more time on security-testing their work and narrowing the options to standard functionality only means that not the solution but the technical capabilities are central and there is a chance that business might get not the solution that they need, not to mention the extra effort required to “just get things done”.

Sandboxed Solutions offer added value to SharePoint developers allowing them to use their knowledge to build secure solutions. And although the API available for Sandboxed Solutions gives developers the ability to interact with data stored in SharePoint, it might be too limited to complete all tasks and provide end users with fully working solutions instead of a collection of building blocks and a manual.

Inconvenient provisioning Web Parts instances from Sandboxed Solutions

One of the challenges when working with Sandboxed Solutions is how to provision Web Parts instances to pages. If you have done this before in a Farm Solution you know, that in order to add a Web Part to a page programmatically in SharePoint you have to retrieve the instance of the SPLimitedWebPartManager class and use it to add the instance of a Web Part to a page. Unfortunately, as the SDK mentions, the SPLimitedWebPartManager class is not available in Sandboxed Solutions which means that you cannot programmatically add a Web Part to a page from within a Sandboxed Solution.

Luckily the programmatic approach isn’t the only option that SharePoint offers for adding Web Parts to pages. It turns out that there is a declarative approach as well, which is just perfect for when you need to provision a Web Part instance from within a Sandboxed Solution.

Declaratively provisioning Web Part instances to pages

Declaratively provisioning Web Part instances to pages is easy and can be done using a Module. The following code snippet shows how you can add a Content Editor Web Part with the Hello world text to a Web Part Page:



  
    
      
        

  Content Editor
  Default
  Allows authors to enter rich text content.
  true
  Left
  0
  Normal
  
  
  true
  true
  true
  true
  true
  true
  true
  
  
  Modeless
  Default
  
  Cannot import this Web Part.
  /_layouts/images/mscontl.gif
  
  Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c
  Microsoft.SharePoint.WebPartPages.ContentEditorWebPart
  
  Hello world
        
        ]]>

Important: to provision a Web Part to a Web Part Page you will need a Web Part Page file. You can copy the default Web Part Page file from 14\TEMPLATE\SiteTemplates\sts\default.aspx.

As you can see adding Web Parts to Web Part Pages is fairly easy. The challenge begins however as soon as you start working with Wiki Pages.

Declaratively provisioning Web Part instances to Wiki Pages

One of the new features introduced with SharePoint 2010 was the concept of adding Web Parts in content. Before that we had to use Content Editor Web Parts to store content if we wanted to use Web Parts in between. With SharePoint 2010 we could just type rich content and insert Web Parts in between just as if we were adding images or tables.

The Web Parts in content capability has been made available in Publishing Sites as well as Collaboration Sites. The only requirement with regards to Collaboration Sites is, that you have to be using Wiki Pages. A while ago I wrote an article about how you can add Web Part instances to content. The approach I presented involved using custom code which unfortunately cannot be used from within Sandboxed Solutions as it relies on the SPLimitedWebPartManager class. However using the same information about how Web Parts in content work behind the scenes, we can alter the declarative approach used for Web Part Pages to add a Web Part to a Wiki Page. The following code snippet presents the Module modified to add the Content Editor Web Part to a Wiki Page:



  
    
      
      
        

  Content Editor
  Default
  Allows authors to enter rich text content.
  true
  Left
  0
  Normal
  
  
  true
  true
  true
  true
  true
  true
  true
  
  
  Modeless
  Default
  
  Cannot import this Web Part.
  /_layouts/images/mscontl.gif
  
  Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c
  Microsoft.SharePoint.WebPartPages.ContentEditorWebPart
  
  Hello world
        
        ]]>

Important: Note that the Wiki Page uses a different page file that can be copied from 14\TEMPLATE\DocumentTemplates\wkpstd.aspx

If you took a careful look at the code snippet you might have noticed that a few things have changed. First of all we changed the page’s URL to SitePages/Home.aspx (line 4) so that it points to a Wiki Page instead of a Web Part Page. Next we added the WikiField property (lines 5-7) which contains the content of the Wiki Page. Although the content is a little difficult to read it contains the HTML marker of Web Part added to content, which after decoding looks like this:

Next, to the AllUsersWebPart tag we added the ID attribute (line 8). Although the SDK doesn’t explain what this attribute is for, it can be used to provision a Web Part with a predefined ID. The only requirement is, that all – (dash) are replaced with _ (underscore) and the ID is prefixed with g_. As you can see the Web Part’s ID corresponds to the ID used in the marker placed in the Wiki Page’s content.

Bonus: Declaratively Provisioning List View Web Parts to Wiki Pages

There are scenarios when you might need to provision a List View Web Part to a Wiki Page. The good news is that the required approach is not much different from provisioning a Content Editor Web Part or any other Web Part for that matter.

If you’ve worked with declaratively provisioning List View Web Parts you know that in order to add a List View Web Part to a page you have to use the View element. For example to add a List View Web Part for the Announements list available in a standard Team Site to a Web Part Page, you would use the following code:

Adding List View Web Parts to content is very similar to adding regular Web Parts. All you need to do is to change the value of the WebPartZoneID attribute to wpz and add the ID attribute to the View element with a GUID specified exactly as if you would for any other Web Part that would be added in content, for example:

Summary

Sandboxed Solutions offer great power and flexibility for extending the SharePoint platform with custom functionality. The price of this empowerment is limited access to the SharePoint API and the .NET Framework. One of the common tasks which is affected is provisioning Web Part instances to pages. Although the programmatic approach is not available to SharePoint developers, the declarative way is a good alternative.

Easier using widgets in SharePoint 2010 with the Mavention Widget Web Part

Waldek Mastykarz — Fri, 27 Jan 2012 14:59:05 +0000

In my previous article I explained why using widgets in SharePoint 2010 is inconvenient and showed what you can do to make it easier using the standard functionality. In this article I’ll show you how you can simplify working with widgets even further using the Mavention Widget Sandboxed Web Part.

Mavention Widget Web Part

The Mavention Widget Web Part is a Sandboxed Web Part which allows you to include in the page any snippet of HTML without any restrictions. Although from the functionality point of view this Web Part doesn’t seem like much, it’s offering you a lot of flexibility and simplifies the maintenance of your pages.

In order to use the Mavention Widget Web Part you have to activate the Mavention Widget Web Parts Package first. Since it is a Sandboxed Solution you can do it by opening the Site Settings and navigating to the Solution Gallery.

After uploading and activating the Mavention Widget Web Parts Package the Mavention Widget Web Parts Feature is installed. Because it’s a Site Collection-scoped Feature it is also automatically activated allowing you to directly start with including widgets on your pages.

After activating the Solution Package navigate to the page where you would like to insert a widget, edit the page and from the Insert tab click the Web Part button.

From the Categories list choose Mavention Web Parts (1), select the Widget Web Part (2) and click the Add button (3) to add the Web Part.

After adding the Web Part, edit its properties and from the Widget Web Part section click the Edit… button.

Next, in the dialog window, paste the contents of your widget and confirm changes by clicking the OK button.

After you confirm changes the widget will appear in the Web Part.

Editing the widget is just as easy as adding it. All you need to do is to open the Widget Web Part’s properties, click the Edit… button and you will see the widget’s code just as you pasted it.

Download: Mavention Widget Web Part (5KB, Sandboxed WSP)

Inconvenient using widgets in SharePoint for end users

Waldek Mastykarz — Fri, 27 Jan 2012 09:36:27 +0000

It’s a common approach to use widgets to enrich web solutions. Unfortunately using widgets with SharePoint 2010 has a number of challenges. Find out why using widgets with SharePoint is inconvenient and how you can simplify it.

Widgets – they’re everywhere

In the last few years many web services started providing widgets so that their services can be integrated with websites. After all, who haven’t heard about the twitter search widget, the facebook like button, or about embedding a YouTube video in a page. The great thing about widgets is that they allow non-technical users to enrich their sites with dynamic functionality with nothing more than a few mouse clicks.

Flexibility vs. security

Many organizations that use SharePoint, no matter whether those are intranet portals on public-facing websites, want to be able to use widgets as well. Unfortunately when it comes to using widgets with SharePoint things aren’t as easy as you might have wanted them to be.

From the integration perspective, there are a number of ways in how you could integrate widgets into a SharePoint website. Although from the development point of view the integration capabilities are virtually limitless, it’s empowering the end users that many organizations are interested in. Assuming users have no permissions to modify Master Pages and Page Layouts, they can use widgets either by including them directly in content or by using the Content Editor Web Part.

Using scripts isn’t without risk. Considering how powerful client-side scripting is, when put in wrong hands, harmful scripts could cause damage. Not to mention that overusing widgets will very likely have a negative impact on the performance and can turn your website into a christmas tree. To protect users from all kinds of client-script attacks SharePoint has some protective precautions implemented.

Using widgets in SharePoint 2010 for end users

As a sample let’s try to use the twitter search widget.

The twitter search widget uses the following code snippet that should be added to the page:

Using widgets in-line

The first option to use widgets is to paste their HTML code directly in the page’s content. When you paste the widget’s code into a Publishing HTML field, everything seems to be okay at first.

Although you will see the warning mentioning that the HTML source might have been modified, the widget’s code is still there just as you pasted it if you go back to the HTML source view.

If you however save the page and once again open the HTML source you will see that all the widget code has been removed.

Using widgets with the Content Editor Web Part

Another approach to use widgets with SharePoint that you might consider is by using the Content Editor Web Part (CEWP) and paste the widget’s contents there. Because the CEWP is not based on the Publishing HTML field, it shouldn’t theoretically have the same restrictions.

Let’s start off by adding a new Content Editor Web Part. It doesn’t really matter whether you insert it in content or in a Web Part Zone. Next, edit the Web Part’s content and paste the widget’s code into the CEWP’s HTML source.

Although, once again, you will see the warning about the HTML source being possibly modified, when you save the page the widget will appear on the page.

Imagine however, that at some point you wanted to change something about the widget. The moment you choose to edit the CEWP’s content, the widget will appear twice in the contents!

Although the widget doesn’t disappear, it’s almost impossible to modify it once added to the page. Every time you would need to change something about the widget you would have to reinsert it on the page.

It’s worth noting that you won’t experience this behavior with all widgets. Embedding YouTube videos for example works okay, as the widget consists only of an iframe which is rendered properly within a Content Editor Web Part.

Using widgets with the Content Editor Web Part and external files

Editing HTML directly in the Content Editor Web Part is not the only way to make it display some content. The CEWP also allows you to embed a piece of HTML from an external file. The great thing about it is that the CEWP doesn’t use iframe but embeds the HTML file directly in the page which is great for using widgets.

Embedding widgets by linking a Content Editor Web Part doesn’t introduce any limitations and works as you would expect it to, allowing you to embed all kinds of widgets in SharePoint pages.

The only downside of using this approach is that every widget has to be a separate file stored somewhere in your Site Collection. Unless you have a good strategy of how to keep track which file contains what widget, you can very easily loose track of them – especially if you’re using multiple different widgets across your site. Luckily SharePoint offers you a little help.

Tracking usage of widget files

You can track usage of your widget files within your Site Collection by using the Manage Content and Structure tool. For this, from the Site Actions menu choose the Manage Content and Structure option.

Next, in the tree view select the Document Library that contains your widget files.

In the Documents View open the drop-down menu of the file for which you want to see where it’s being used on the Site Collection and choose the View Related Resources option.

After clicking the option, the Document View will split and the bottom part of the screen will contain a list of all the pages where the widget file is being used on.

Summary

Widgets can help you enrich your website and surface content from other sources. Unfortunately using widgets on SharePoint websites is not without challenges. Embedding widgets’ code in separate files and linking to them using the Content Editor Web Part is the only way available using the standard functionality to embed widgets on pages. To keep track of where which widgets are being used you can use the Manage Content and Structure tool provided with SharePoint. In the next article I will show you how you can embed widgets in pages using the Mavention Widgets Sandboxed Web Part if you find working with external files too inconvenient.

Better content targeting with Mavention Negated Audiences

Waldek Mastykarz — Tue, 24 Jan 2012 06:51:29 +0000

One of the frequent challenges when working with Audiences is the inability to provide alternative content to users outside the Audiences to which the content is targeted. Find out how to prevent pages from getting blank with Mavention Negated Audiences.

SharePoint 2010 Audiences 101

The Audiences capability provided with SharePoint 2010 allows you to target content to specific groups of users. By leveraging Audiences you can not only unclutter the user interface but also make the solution more useful to the users by showing them relevant content.

Targeting content using Audiences in SharePoint 2010 is easy. Assuming you have configured Audiences in the User Profile Service Application, all you need to do is to navigate to a site, choose the Web Part that you want to display to specific audiences and in its properties select the desired Audiences.

After you apply the changes and you navigate to that page as a user who is a member of the selected Audience, you should see the Web Part as intended.

If you however navigate to the same page as a user who isn’t a part of the selected Audience, you won’t see the Web Part.

Although this works as intended, in many scenarios an empty spot or even a blank page is not good enough. In fact often content managers would like to be able to present alternative content to all users who are not a member of specific Audiences.

Targeting content to everyone but the Audience

One approach that you might consider for presenting alternative content to users who are not a part of specific Audiences is to create another Audience which contains all those users and target content to that Audience. This process can be challenging depending on the Audience rules: while it might be easy to create 18+ and 18- Audiences, you cannot really create an Audience with all users who don’t belong to a certain SharePoint group. Additionally this approach increases the solution maintenance effort as for every user group you have to maintain two Audiences instead of one.

Another approach worth considering is content targeting by negating the Audiences. Although it’s not available out of the box, it is a powerful approach that leverages the extensibility capabilities of the SharePoint 2010 platform. By extending the existing content targeting functionality, all you need to do is to add an option that allows you to negate the selection.

Targeting content using Mavention Negated Audiences

Mavention Negated Audiences is a SharePoint 2010 solution that extends the standard content targeting capabilities with negating audiences making it very easy to display alternative content to users who are not a member of specific Audiences.

Before you start targeting content using Mavention Negated Audiences, there is some configuration that needs to be done. Another thing that you should keep in mind is, that Mavention Negated Audiences extends the standard Audiences capability of SharePoint 2010. If you would like to stop using it at some point you would need to reconfigure all Web Parts where you used Negated Audiences (you checked the Negate Audiences checkbox). Considering there is not alternative functionality available out of the box you would very likely remove those Web Parts anyway.

Prerequisites

In order to use Mavention Negated Audiences you first need to install the Solution Package and deploy it in your Farm. Next, you have to select a Web Application where you want to use Mavention Negated Audiences, and enable the Mavention Negated Audiences Web Application Feature.

With that you can start targeting content to your users.

Working with Mavention Negated Audiences

Imagine you had a page where you would like to display one message to all managers and another to all other users. For this purpose you created the Managers Audience in the User Profile Service Application.

The first thing that we need to do is to add the message to managers to page and target it to the Managers Audience – just as we would do using the standard SharePoint 2010 Audiences functionality.

Next, let’s add another Web Part that will contain the alternative message that should be displayed to all users who are not managers. In the Audiences field choose once again the Managers Audience, but this time check the Negate Audiences checkbox as well.

This will cause the Web Part to be displayed to all users who are not a member of the Managers Audience. Confirm your changes by clicking the OK button.

To test if everything is working correctly I have created two users: Joris (manager) and Waldek (employee). When I navigate to the announcement page as Joris, I will see the management announcement – as expected using the standard functionality.

If I however navigate to the same page as Waldek I will see the alternative announcement!

As you can see providing alternative content to users outside specific Audiences using Mavention Negated Audiences is very easy and adds minimal maintenance effort.

Summary

Using the Audiences capability of SharePoint 2010 you can target content to specific groups of users providing them with relevant content. One of the common limitation of the standard Audiences mechanism is the inability of providing alternative content to users who are not a member of the specific Audiences. With the Mavention Negated Audiences solution you can target content to both specific Audiences as well as all other users providing a complete experience to all your users.

Download: Mavention Negated Audiences (WSP, 6KB)

Granting permissions to the User Profile Service Application using PowerShell

Waldek Mastykarz — Fri, 20 Jan 2012 14:12:16 +0000

In my previous article I explained how access permissions to the User Profile Service Application are required if you want to programmatically configure Navigation of a Publishing Site in SharePoint 2010. In the article I showed you how you can configure grant required permissions manually. There are however scenarios when you might need to configure those permissions in a structured and repeatable way. Find out how to grant permissions to the User Profile Service Application using PowerShell.

It’s all about having access

Previously I showed you how to avoid an exception being throw while configuring Navigation for a Publishing Site in SharePoint 2010. Because Navigation configuration requires internally the access to Audiences information, the account that you are using to execute the navigation configuration PowerShell script has to have sufficient permissions to access the User Profile Service Application where the Audiences information is stored.

As I explained previously you can configure those permissions by navigating to Central Administration and from the Application Management group clicking the Manage service applications link.

Next, from the list of available Service Applications, select the User Profile Service Application and in the Ribbon, from the Sharing group, click the Permissions button.

Add the account that you are using to execute the navigation configuration PowerShell script (1) and give it Full Control permissions (2). Confirm your changes by clicking the OK button (3).

The interesting part is, that if you go back to the Permissions screen, you will see that the permissions to the User Profile Service Application are granted to an identity claim generated using the previously provided account and not the user object itself.

This is an important detail that we have to take into account while building the PowerShell script.

Configuring User Profile Service Application permissions using PowerShell

You can configure User Profile Service Application permissions using the following PowerShell script:

param (
    $accountName
)

$claimType = "http://schemas.microsoft.com/sharepoint/2009/08/claims/userlogonname"
$claimValue = $accountName
$claim = New-Object Microsoft.SharePoint.Administration.Claims.SPClaim($claimType, $claimValue, "http://www.w3.org/2001/XMLSchema#string", [Microsoft.SharePoint.Administration.Claims.SPOriginalIssuers]::Format("Windows"))
$claim.ToEncodedString()

$permission = [Microsoft.SharePoint.Administration.AccessControl.SPIisWebServiceApplicationRights]"FullControl"

$SPAclAccessRule = [Type]"Microsoft.SharePoint.Administration.AccessControl.SPAclAccessRule``1"
$specificSPAclAccessRule = $SPAclAccessRule.MakeGenericType([Type]"Microsoft.SharePoint.Administration.AccessControl.SPIisWebServiceApplicationRights")
$ctor = $SpecificSPAclAccessRule.GetConstructor(@([Type]"Microsoft.SharePoint.Administration.Claims.SPClaim",[Type]"Microsoft.SharePoint.Administration.AccessControl.SPIisWebServiceApplicationRights"))
$accessRule = $ctor.Invoke(@([Microsoft.SharePoint.Administration.Claims.SPClaim]$claim, $permission))

$ups = Get-SPServiceApplication | ? { $_.TypeName -eq 'User Profile Service Application' }
$accessControl = $ups.GetAccessControl()
$accessControl.AddAccessRule($accessRule)
$ups.SetAccessControl($accessControl)
$ups.Update()

First we generate the identity claim using the account name for which we want to grant access permissions (lines 5-8). Next we generate an access rule for the identity claim and the FullControl permission (lines 12-15). Finally we retrieve the User Profile Service Application (line 17) and we add the newly created access rule (lines 18 and 19). To persist the changes we have to replace the existing AccessControl object with the new one by calling the SPIisWebServiceApplication.SetAccessControl method (line 20) and update the User Profile Service Application object (line 21).

If you for example would like to grant access to the User Profile Service Application to the win2008\administrator account, you would execute the PowerShell script as follows:

.\Set-UpsConnectionPermission.ps1 "win2008\administrator"

This would grant the access permissions to the win2008\administrator account required to programmatically configure Navigation of a Publishing Site in SharePoint 2010.

Programmatically configuring menu items in SharePoint 2010 revisited

Waldek Mastykarz — Fri, 20 Jan 2012 09:51:54 +0000

A while ago I wrote about how you can programmatically configure menu items in SharePoint 2010 using PowerShell. Unfortunately it turns out that it doesn’t always the way you would expect it to. Find out how to get the script working in your SharePoint environment.

Being able to programmatically configure menu items is an quite important part of structured and repeatable deployment. Particularly if you’re building and deploying frequently, configuring navigation can save you quite some time and make it easier for you to run automated tests.

Back in June I shared with you a PowerShell script that allowed you to automatically configure navigation on a Publishing Site built on the SharePoint 2010 platform. While that script worked on my development machine, at some point I started receiving some error reports about it failing in other environments. Every time you would execute the script you would get the following error:

Exception calling "GetNavigationChildren" with "6" argument(s): "Object reference not set to an instance of an object."

As you might have expected, the navigation would remain in its original state.

What is wrong and how to fix it

It turns out that while working with Navigation SharePoint also requests Audiences information. This is not that surprising considering that SharePoint allows you to target navigation item to audiences.

The exception I have just showed you is being thrown because the account that you are using to run the PowerShell script is not allowed to access Audiences information from the User Profile Service Application.

To solve this issue, you have to grant your account permission to access the User Profile Service Application. You can do this by navigating to Central Administration and from the Application Management group clicking the Manage service applications link.

Next, from the list of available Service Applications, select the User Profile Service Application and in the Ribbon, from the Sharing group, click the Permissions button.

Add the account that you are using to execute the navigation configuration PowerShell script (1) and give it Full Control permissions (2). Confirm your changes by clicking the OK button (3).

If you execute the script now, you should see it working as expected.

One more thing

Once in a while the navigation configuration script throws another exception when retrieving navigation nodes. This happens when the Application Pool haven’t been warmed up and the information about navigation nodes has not been made available yet. To avoid this error I have extended the script with a call to the home page of the site, to start the Application Pool and ensure that all the information is in place before we start working with it.

Write-Host "Warming up site $($WebUrl)..." -NoNewline
$wc = New-Object System.Net.WebClient
$wc.UseDefaultCredentials = $true
$wc.DownloadString($WebUrl) | Out-Null
Write-Host "DONE" -ForegroundColor Green

The updated version of the script looks as follows:

param (
    $SiteUrl = "http://publishing"
)

function Set-Navigation {
    param (
        $WebUrl,
        $MenuItems
    )

    Write-Host "Warming up site $($WebUrl)..." -NoNewline
    $wc = New-Object System.Net.WebClient
    $wc.UseDefaultCredentials = $true
    $wc.DownloadString($WebUrl) | Out-Null
    Write-Host "DONE" -ForegroundColor Green

    $site = New-Object Microsoft.SharePoint.SPSite($WebUrl)
    $web = $site.OpenWeb()

    # fake context
    [System.Web.HttpRequest] $request = New-Object System.Web.HttpRequest("", $web.Url, "")
    $sw = New-Object System.IO.StringWriter
    $hr = New-Object System.Web.HttpResponse($sw)
    [System.Web.HttpContext]::Current = New-Object System.Web.HttpContext($request, $hr)
    [Microsoft.SharePoint.WebControls.SPControl]::SetContextWeb([System.Web.HttpContext]::Current, $web)

    # initalize what has to be initialized
    $pweb = [Microsoft.SharePoint.Publishing.PublishingWeb]::GetPublishingWeb($web)
    $dictionary = New-Object "System.Collections.Generic.Dictionary``2[[System.Int32, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089],[Microsoft.SharePoint.Navigation.SPNavigationNode, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c]]"
    $collection = $pweb.Navigation.GlobalNavigationNodes

    # get current nodes
    $globalNavSettings = New-Object System.Configuration.ProviderSettings("GlobalNavSiteMapProvider", "Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapProvider, Microsoft.SharePoint.Publishing, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c")
    $globalNavSettings.Parameters["NavigationType"] = "Global"
    $globalNavSettings.Parameters["EncodeOutput"] = "true"
    [Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapProvider] $globalNavSiteMapProvider = [System.Web.Configuration.ProvidersHelper]::InstantiateProvider($globalNavSettings, [type]"Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapProvider")
    [Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapNode] $currentNode = $globalNavSiteMapProvider.CurrentNode
    $children = $currentNode.GetNavigationChildren([Microsoft.SharePoint.Publishing.NodeTypes]::Default, [Microsoft.SharePoint.Publishing.NodeTypes]::Default, [Microsoft.SharePoint.Publishing.OrderingMethod]::Manual, [Microsoft.SharePoint.Publishing.AutomaticSortingMethod]::Title, $true, -1);

    # reorder nodes
    [Array]::Reverse($menuItems)
    $menuNodes = New-Object System.Collections.ObjectModel.Collection[Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapNode]
    foreach ($node in $children) {
        $menuNodes.Add($node)
    }

    foreach ($menuItem in $menuItems) {
        $node = $null
        foreach ($p in $menuNodes) {
            if ($p.InternalUrl -eq $menuItem) {
                $node = $p
                break
            }
        }

        if ($node -ne $null) {
            [void] $menuNodes.Remove($node)
            [Void] $menuNodes.Insert(0, $node)
        }
    }

    foreach ($node in $menuNodes) {
        Write-Host "$($node.InternalUrl)..." -NoNewline
        $quickId = Get-QuickId $node
        if ($quickId -ne $null -and $quickId.Length -gt 0) {
            [string]$typeId = $null;
            if (($node.Type -eq [Microsoft.SharePoint.Publishing.NodeTypes]::Area) -or ($node.Type -eq [Microsoft.SharePoint.Publishing.NodeTypes]::Page)) {
                if ($node.PortalProvider.NavigationType -eq [Microsoft.SharePoint.Publishing.Navigation.PortalNavigationType]::Current) {
                    $typeId = [Microsoft.SharePoint.Publishing.Navigation.PortalNavigationType]::Current.ToString() + "_" + $node.Type.ToString()
                }
                else {
                    $typeId = [Microsoft.SharePoint.Publishing.Navigation.PortalNavigationType]::Global.ToString() + "_" + $node.Type.ToString()
                }
            }
            else {
                $typeId = $node.Type.ToString();
            }

            $id = $quickId.Split(',');
            $objId = New-Object Guid($id[0]);
            $nodeId = [System.Int32]::Parse($id[1]);

            $navigationNode = Get-NavigationNode $objId $nodeId $node.InternalTitle $node.InternalUrl $node.Description $node.Type $node.Target $node.Audience $collection $dictionary
            $containsNode = $false
            foreach ($mi in $menuItems) {
                if ($mi -eq $node.InternalUrl) {
                    $containsNode = $true
                    break
                }
            }

            if ($containsNode) {
                $pweb.Navigation.IncludeInNavigation($true, $objId)
            }
            else {
                $pweb.Navigation.ExcludeFromNavigation($true, $objId)
            }

            Write-Host "DONE" -ForegroundColor Green
        }
        else {
            Write-Host "SKIPPED" -ForegroundColor Yellow
        }
    }

    $pweb.Web.Update()

    [System.Web.HttpContext]::Current = $null
}

function Get-QuickId {
    param (
        [Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapNode] $node
    )

    $quickId = $null

    $portalSiteMapNodeType = $node.GetType()
    $QuickId = $portalSiteMapNodeType.GetProperty("QuickId", [System.Reflection.BindingFlags] "Instance, NonPublic")
    $quickId = [string] $QuickId.GetValue($node, $null)

    $quickId
}

function Get-NavigationNode {
    param (
        [Guid] $objId,
        [int] $nodeId,
        [string] $name,
        [string] $url,
        [string] $description,
        [Microsoft.SharePoint.Publishing.NodeTypes] $nodeType,
        [string] $target,
        [string] $audience,
        [Microsoft.SharePoint.Navigation.SPNavigationNodeCollection] $collection,
        $oldDictionary
    )

    [Microsoft.SharePoint.Navigation.SPNavigationNode] $node = $null
    if (($objId -ne [Guid]::Empty) -and ($nodeId -ge 0)) {
        if ($oldDictionary.TryGetValue($nodeId, [ref]$node)) {
            $oldDictionary.Remove($nodeId)
            $node = [Microsoft.SharePoint.Publishing.Navigation.SPNavigationSiteMapNode]::UpdateSPNavigationNode($node.Navigation.GetNodeById($node.Id), $null, $name, $url, $description, $target, $audience, $false)
            $node.MoveToLast($collection)
        }

        return $node;
    }

    $node = [Microsoft.SharePoint.Publishing.Navigation.SPNavigationSiteMapNode]::CreateSPNavigationNode($name, $url, $nodeType, $collection);
    return [Microsoft.SharePoint.Publishing.Navigation.SPNavigationSiteMapNode]::UpdateSPNavigationNode($node, $null, $name, $node.Url, $description, $target, $audience, $false);
}

Write-Host "Configuring Navigation..."
$menuItems = "/site1", "/site2", "/site3", "/site4", "/site5", "/site5"
Set-Navigation $SiteUrl $menuItems
Write-Host "Navigation Configuration completed" -ForegroundColor Green

Summary

Configuring navigation as a part of structured and repeatable deployment can save you time and help you automate the testing process. In order to configure navigation on Publishing Sites in SharePoint 2010 the account that executes the configuration script must be granted access to the User Profile Service Application which contains information about Audiences which is used by SharePoint 2010 to target navigation items to specific groups of users.

Why automatic creation of variation sites and pages can be harmful

Waldek Mastykarz — Tue, 17 Jan 2012 09:27:45 +0000

When working with Variations, using the option to automatically create variation pages is very tempting. Unfortunately, if used improperly, it can have negative impact on the search ranking of your website.

Variations as approach for supporting multilingual sites

A common approach to implement multilingual solutions on the Microsoft SharePoint 2010 platform is to use Variations. Although Variations can be used for other purposes as well, delivering content in multiple languages is probably the most common usage scenario.

Before you start working with Variations you have to configure how you want them work. There are a few options to set such as whether you want to copy resources or reuse them from a centralized location. All the necessary settings can be controlled from the Variation Settings page.

One of the options that you can configure is Automatic Creation of variation pages.

By configuring this option to Automatically create site and page variations every time you create a site or publish a page, draft versions in all defined variations will be created automatically. And this is when things may go wrong.

Why automatically creating variation pages may be harmful

If you’re using Variations to deliver content to multiple devices you will very likely be okay and using the automatic variation pages creation will do you no harm. It’s using Variations for delivering multilingual content to users that deserves additional consideration.

The way automatic variation pages creation works is that every time you create a site, a site with the same name (URL) will be created in all variation labels. Comparably, every time you publish a page, a draft version of that page will be created in all variation labels. The problem is that the created sites and pages will have exactly the same URL as the site/page in the source label and the only difference will be the variation label’s name. To illustrate this problem let’s take a look at the following example.

An example of how things go wrong

Let’s say we had a website with an About Us section and within it a Careers page with an overview of all the job offers. Assuming the English variation label is the source label, the Careers page could have the following URL:

/en/about-us/pages/careers.aspx

An English-speaking person searching for careers would have a hit on the careers word in the URL what would cause the page rank relatively high in the search results.

If we used automatic variation pages creation, after publishing the English Careers page, the variations engine would create a draft in the Dutch label using the following URL:

/nl/about-us/pages/careers.aspx

Important: Because creating variations sites and pages in SharePoint 2010 is being done using Timer Jobs it can take a moment for them to be created.

And although most content editors edit the site’s/page’s title, the URLs remain unchanged.

Even if you don’t speak Dutch, you can imagine that neither about-us nor careers mean anything in Dutch. With that in mind, the odds are high that a Dutch-speaking person would be less likely to find our Careers page when looking for job offers in Dutch (vacatures).

As you can see, because the URL is one of the most important metrics for determining the ranking of pages in search results using automatic variation pages and sites creation is very bad for your website! Not only it makes the content more difficult to find but it also make the URLs more difficult to understand.

If you’re using automatic variation pages creation, you can still change the URL after the draft version has been created. But why not consider creation variation pages manually and prevent problems from occurring in the first place?

Manually creating variation sites and pages

The process of manually creating variations sites and pages begins with configuring the Automatic Creation option in the Variations Settings page to Do not automatically create site and page variations. This can be done before you create variation hierarchies as well as after you have created them.

The next time you create a site or publish a page only that particular site/page will be created. You will have to create the variation sites and pages in all variations yourself. While this might seem tedious, it allows you to explicitly define the URLs of the created sites and pages right from the beginning.

Creating variation pages

Creating variation pages is very simple and can be done using the Ribbon. To create a variation for a page navigate to that page and in the Ribbon activate the Publishing tab. Next, from the Variations group click the Create button.

Important: For the Create Variation button to be active the page that you want to create variation for has to have at least one minor version created.

After that you will see the New Page Variation page where you can provide the Title and the URL of the variation page, select the Page Layout that you want to use and choose the variation label in which you want this page to be created.

After you click the Create button, a new variation page will be created.

Creating variation sites

Comparing to creating page variations, creating site variations is a little less convenient. If you look in the Ribbon or on the Site Settings page, you won’t find any option there that would allow you to create a site variation.

Using the standard SharePoint 2010 functionality creating site variations is possible only using the Manage Content and Structure tool. To create a site variation, from the Site Actions menu click the Manage Content and Structure option. Next, open the context menu for a site for which you want to create variation and select the New > Site Variation option.

You will be redirected to the New Variation Site page where you will be able to select the variation label in which you want to create the site variation and you will be able to provide the Title and the URL of the variation site.

After you click the OK button, the variation site will be created.

Important: Similarly to page variations, site variations are created using Timer Jobs so it might take a moment before you will be able to open the site variation that you have just created.

As you can see, because you are creating pages and sites variations manually, you have to explicitly provide the name (URL) for the site/page in the given language. With that there is much more chance that sites and pages will be created in the language related to the specific variation label.

Summary

When working with multilingual websites, SharePoint 2010 offers the Variations capability to support managing content in all the different languages. When working with Variations many content managers choose to use automatic site and page variation creation. The downside of this approach is that URLs on which the sites and pages are created don’t reflect the specific variation language. Although it is not impossible to change the URLs afterwards, it might be worth considering to change the variation creation process to manual and to help content managers think about translating the URL to optimize the content for search engines.

Correctly implementing Ribbon in SharePoint 2010

Waldek Mastykarz — Fri, 13 Jan 2012 11:02:57 +0000

SharePoint 2010 introduces a new User Experience designed to make it easier for users to accomplish their tasks. One of the biggest improvements is the contextual Ribbon, which increases discoverability op options by displaying only options relevant to the current context. The main idea behind the Ribbon is that it’s always available and within reach. This applies not only to Office client applications but also to SharePoint.

Positioning the Ribbon

Following Microsoft’s guidelines, the Ribbon should always float at the top of the page. And although SharePoint 2010 provides us with a mechanism to position the Ribbon correctly, there is some work that needs to be done by us as well.

When creating new Master Pages, you will be very likely using either the Starter Master Pages for SharePoint 2010, made by fellow SharePoint MVP – Randy Drisgill, or one of the standard SharePoint Master Pages as a starting point. No matter your preference, in both cases you will be provided with all the necessary components to get the Ribbon positioned correctly. It’s upgrading existing SharePoint 2007 Master Pages that requires extra attention to ensure that you get all the necessary components in place.

How they do it: Floating Ribbon

SharePoint 2010 uses a rather complex approach to make the Ribbon float on the top of the page. On every page load, page’s height is being measured using JavaScript and the Ribbon and body are sized using those dimension. In order for this process to be executed SharePoint requires your Master Page to contain elements with the following ID’s: s4-ribbonrow, s4-workspace and s4-bodyContainer. If you haven’t defined one of those ID’s, the Ribbon positioning logic will not be executed.

The logic behind positioning the Ribbon is implemented in the init.js file in the FixRibbonAndWorkspaceDimensions function (line 3406; the exact position may depend on your patching level). In lines 3409-3412 how different prerequisite elements are being retrieved and how SharePoint checks in line 3413-3415 if all the required elements have been defined.

So whenever you have problems getting the Ribbon positioning to work, don’t forget to check if you have all those ID’s defined properly in your Master Page. Using standard Master Pages such as v4.master or nightandday.master is always a good idea to verify that you have done everything correctly.

Summary

SharePoint 2010 introduces the Ribbon to make it easier for users to accomplish their tasks. One of the ideas behind the Ribbon is that it’s always within the reach so that users can easily discover functionality they need at the given moment. Correctly laying out the Ribbon can be achieved using the standard SharePoint 2010 functionality but requires placing specific elements to get it to work.

Microsoft SharePoint 2010 Development Cookbook–book review

Waldek Mastykarz — Tue, 10 Jan 2012 12:38:36 +0000

Recently I had the opportunity of reviewing a brand new book for SharePoint developers – the Microsoft SharePoint 2010 Development Cookbook written by fellow SharePoint MVP Ed Musters.

What I expected

Following the title I expected a cookbook: a collection of recipes that illustrate common good practices in developing SharePoint solutions. There are many books about development on the SharePoint platform so I expected this cookbook to be different and offer the reader some added value. An idea of having recipes that you can browse whenever you don’t need all the explanation but just need an overview of steps to follow to get things done seems very appealing to me.

Considered the audience (experienced ASP.NET developers) I expected to see a mix of basic and complex recipes that demonstrate how different things can be achieved in SharePoint.

What I got

The first recipe in Ed’s book presents how to create a development environment. If you’ve been working with SharePoint already, it might not be the most interesting part of the book, but you should definitely read it, if you are new to developing on the SharePoint platform and look for guidance on how to start.

Following recipes present common tasks in SharePoint development as step-by-step guides. The good thing about how the book is structured is that every chapter starts from the beginning so you’re not required to read the whole book. Instead you can skip directly to the part that you are interested in. Although not every recipe clearly describes its goal at the beginning, they are still easy to follow because they are brief and focus on one topic only. Creating List Forms with InfoPath and using the Data Form Web Part to display external data are just two examples of recipes that Ed presents in his book.

Development on the SharePoint platform is very different depending on which workload you are working with and whether your projects require structured and repeatable deployment or if you can customize things using SharePoint Designer. Ed doesn’t go very deeply into Application Lifecycle Management of SharePoint Solutions but he does present recipes that require Visual Studio as well as recipe that can be done using SharePoint Designer.

Ed closes his book with, in my opinion, somewhat misplaced chapter presenting non-developer overview of Web Content Management capabilities of the SharePoint 2010 platform. Although the chapter sticks with the recipe format, considering the audience, the recipes should be developer-oriented instead only presenting WCM configuration capabilities of the SharePoint 2010 platform.

Summary

The book is written with experienced ASP.NET developers in mind. Because it’s a cookbook, the book consists of short recipes rather than explaining every aspect of development on the SharePoint platform in depth. Depending whether you learn through theory or if you prefer hands-on experience, you might prefer some additional reading before picking Ed’s book to get more understanding of how the different pieces of the SharePoint platform fit into each other. Ed’s book is a valuable resource if you have not that much experience with SharePoint and are looking for a proven approach to accomplish specific tasks.

SharePoint Server MVP 2012

Waldek Mastykarz — Sun, 01 Jan 2012 16:18:03 +0000

I have just received an e-mail from Microsoft saying that I have been reawarded the Microsoft Most Valuable Professional (MVP) for SharePoint Server title for another year.

Herewith I would like to thank everyone in the SharePoint community for inspiration and their continuous feedback on my work. Thank you!