Recently I was challenged with the task to set the layout and content of a wiki page when a new page is added to a team site. As I am used to work with SharePoint publishing, the task sounded easy, but I was wrong.

Text Layout

My first path was to figure out where SharePoint puts the wiki “text layouts”. I discovered this is not how it works. The layouts available for wiki’s are not configurable anywhere.

But using some PowerShell it was easy to get and set the layout as it is the HTML content of the “Wiki Field” column in the list.

$web = Get-SPWeb http://server/teamsite
$list = $web.Lists["Site Pages"]
$listItem = $list.Items[2] # My test page
$listItem["Wiki Content"] # Returns HTML

The HTML content consists of two parts. The layout table and the layout data.

<table id="layoutsTable" style="width: 100%">
  <tbody>
    <tr style="vertical-align: top">
      <td style="width: 100%">
        <div class="ms-rte-layoutszone-outer" style="width: 100%">
          <div class="ms-rte-layoutszone-inner"></div>
        </div>
      </td>
    </tr>
  </tbody>
</table>
<span id="layoutsData" style="display: none">false,false,1</span>

The layout data describes visibility of the header and footer and the number of columns.

Event receiver

To set the content the first thing in my mind was to add an ItemAdding event receiver, associated with ListTemplateId 119 (WebPageLibrary).

I deployed the solution and added a page and 🎉: no content!

Using the debugger to verify my event receiver was triggered, I went to the next option: adding an ItemAdded event receiver. This time I got an exception the page was already modified by another user. Refreshing the page gave me the default content.

So, this told me 2 things:

1. It is possible to set default content
2. I forgot to set the Synchronize property

So, after fixing the second thing, I deployed once again and got: no content!

As I used ListItem.Update method in my receiver, I got a version history where it showed the content was set, but the final version still ended up empty.

When faced with utter desperation, working with SharePoint has taught me you always have an escape: launch Reflector.

There I found this gem of code in the SubmitBtn_Click method of the CreateWebPage Class:

SPFile file = SPUtility.CreateNewWikiPage(wikiList, serverRelativeUrl);
SPListItem item = file.Item;
item["WikiField"] = "";
item.UpdateOverwriteVersion();

So, no matter what I do in ItemAdding or ItemAdded, the content always ends up empty!

After this discovery, the fix was removing the code from the ItemAdding and ItemAdded events and moving it to the ItemUpdated method (synchronous) and added a check if the WikiField content is an empty string.

public override void ItemUpdated(SPItemEventProperties properties)
{
    base.ItemUpdated(properties);

    var listItem = properties.ListItem;

    if (!string.IsNullOrEmpty(listItem["WikiField"] as string))
    {
        return;
    }

    this.EventFiringEnabled = false;

    listItem["WikiField"] = html;
    listItem.UpdateOverwriteVersion();

    this.EventFiringEnabled = true;
}

Now every wiki page I add to the team site contains the correct text layout and contains the default HTML.

With SharePoint it is easy to configure multiple zones for your SharePoint Web Application. For example, you have a Publishing Web Site with two zones.

1. The authenticated CMS where editors can manage content: https://cms.int
2. The anonymous website where everybody can view the content: http://www.ext

When the editors link to sites, pages, documents and images the URL will start with https://cms.int. After the content is published it’ll also be available on the anonymous site. Now most of the URLs will be automatically translated to corresponding zone URL and start with http://www.ext.

However, there are some places where this is not the case. You could try to use relative URLs but even that will not fix every scenario.

Translate the URL using code

Facing this issue, I had to translate the URLs myself. But I want to write minimal code. Luckily, Microsoft has done most of the work for me.

On the SPFarm class you will find the AlternateUrlCollections property. This “collection” is actually an instance of the SPAlternateUrlCollectionManager class and provides the RebaseUriWithAlternateUri method.

And this is where the magic happens.

This method has an overload where you supply a Uri and a SPUrlZone. You can provide one of the values of the SPUrlZone enumeration or you can provide the current zone.

To get your current zone you can use the static Lookup method of the SPAlternateUrl class. This method requires a Uri so we provide the current one using the ContextUri property from the same class.

To wrap it all up I give you the code:

var originalUri = new Uri("https://cms.int/pages/default.aspx");

var zone = SPAlternateUrl.Lookup(SPAlternateUrl.ContextUri).UrlZone;

var translateUri = SPFarm.Local.AlternateUrlCollections
                               .RebaseUriWithAlternateUri(originalUri, zone);

// When accessing from the authenticated zone
// translateUri == "https://cms.int/pages/default.aspx"

// When accessing from the anonymous zone
// translateUri == http://www.ext/pages/default.aspx

“Other” URLs

If you pass a URL which is not listed as an Alternate Access Mapping the method will return the original URL.

In a previous article, I have written about “Using the people picker over a one-way trust”. In that post I use STSADM commands as there are no other ways to configure this.

A downside of the STSADM command is your domain password being visible on the command prompt in plain text for everybody to read.

With SharePoint 2010 Microsoft introduces several cmdlets to replace the “old” STSADM commands. But looking at the STSADM to Windows PowerShell mapping you will see the commands for configuring the people picker are not present.

Creating my own script

PowerShell contains the Get-Credential cmdlet which uses a dialog to request credentials from the user and stores the password in a SecureString.

This triggered me to write a PowerShell script which will work the same as “STSADM -o setproperty -pn peoplepicker-searchadforests”, but instead of typing the credentials on the command line it will use the credential dialog for every trusted domain.

As written in my previous post the configuration is done in two steps.

SetAppPassword

First you need to create a secure store for the credentials. This is done by executing the SetAppPassword command on every server in your SharePoint Farm with the same password.

STSADM

stsadm -o setapppassword
       -password <password>

PowerShell

Set-AppPassword "<password>"

function Set-AppPassword([String]$password) {
  $type =
      [Microsoft.SharePoint.Utilities.SPPropertyBag].Assembly.GetType("Microsoft.SharePoint.Utilities.SPSecureString")

  $method =
      $type.GetMethod("FromString", "Static, NonPublic", $null, @([String]), $null)

  $secureString = $method.Invoke($null, @($password))

  [Microsoft.SharePoint.SPSecurity]::SetApplicationCredentialKey($secureString)
}

PeoplePickerSearchADForests

The second step is to register the (trusted) domains to be visible in the people picker. Remember this setting is per web application and zone.

STSADM

stsadm -o setproperty
       -url <url>
       -pn "peoplepicker-searchadforests"
       -pv "forest:<source forest>;domain:<trusted domain>,<trusted domain>\<account>,<password>"

PowerShell

Set-PeoplePickerSearchADForests "<url>"
                                "forest:<source forest>;domain:<trusted domain>"

function Set-PeoplePickerSearchADForests([String] $webApplicationUrl, [String] $value) {
  $webApplication = Get-SPWebApplication $webApplicationUrl

  $searchActiveDirectoryDomains = $webApplication.PeoplePickerSettings.SearchActiveDirectoryDomains
  $searchActiveDirectoryDomains.Clear()

  $currentDomain = (Get-WmiObject -Class Win32_ComputerSystem).Domain

  if (![String]::IsNullOrEmpty($value)) {
    $value.Split(@(';'), "RemoveEmptyEntries") | ForEach {
        $strArray = $_.Split(@(';'))

        $item = New-Object Microsoft.SharePoint.Administration.SPPeoplePickerSearchActiveDirectoryDomain

        [String]$value = $strArray[0]

        $index = $value.IndexOf(':');
        if ($index -ge 0) {
            $item.DomainName = $value.Substring($index + 1);
        } else {
            $item.DomainName = $value;
        }

        if ([Globalization.CultureInfo]::InvariantCulture.CompareInfo.IsPrefix($value, "domain:","IgnoreCase")) {
            $item.IsForest = $false;
        } else {
            $item.IsForest = $true;
        }

        if ($item.DomainName -ne $currentDomain) {
            $credentials = $host.ui.PromptForCredential("Foreign domain trust"
              + " credentials", "Please enter the trust credentials to"
              + " connect to the " + $item.DomainName + " domain", "", "")

            $item.LoginName = $credentials.UserName;
            $item.SetPassword($credentials.Password);
        }

        $searchActiveDirectoryDomains.Add($item);
    }

    $webApplication.Update()
  }
}

Using the script

I have attached the script so you can use it in any way you want. You can put the commands in your own .ps1 file, or load the script in your current session using the following syntax:

. .\<path to file>PeoplePickerSearchADForests.ps1

(Yes, that is a dot, then a space, then the path to the script)

PeoplePickerSearchADForests.zip