This is the fourth article in a series which explores the SharePoint 2010 MySite features. This article will examine the ways that you can customise the default page for the MySite. It will describe the common requirement and how to approach them in a supportable and scalable fashion. The walkthrough will provide an example implementation which you can tailor to your exact needs.

Series contents:

1. Overview, which details the MySite functionality provided by SP2010
2. Anatomy, we delve inside the MySite and dissect its inner secrets
3. Customisation for Branding, how to change the look and feel
4. Customisation of My Content page, how to change the page layout and contents – This Article
5. Customisation of a MySite Blog, how to alter the Blog
6. The MySite centric intranet, putting the MySite at the centre of the universe

The challenge

With the up take of Social media and the focus many organisations are now putting on the MySite capability of SharePoint it is becoming more common for people to want customisations to the default page. Now before we get all excited and break out Visual Studio lets cover some basics. You’re not supported to modify the MySite Personal site definition which provisions the default aspx page. This could have you scratching you chin and turning to ‘Bing’ for answers. You also need to consider things like scale, first time site creation and on going performance and upgradability for future enhancements.

There are a couple of articles out on the web SharePoint Team and CKS MySiteCreate 1.0 Production. These solutions have an interesting approach of stapling modification features and using a control which performs the required page changes during load for the first render. After reading and walking through this approach I can see several things that are not optimal. First it forces you to change the masterpage in order to provision the one containing the actioning control. Second the actioning control itself, to be blunt this ‘smells’ to me.

Using a UI element to perform one time customisation doesn’t feel that smart. Although it only executes on the first page load per user the overhead for the user waiting for the required logic can lead to increased page load after the MySite is created. After testing, this process was found to often fail to execute in time and the user had a strange experience where the page sometimes looked empty until a refresh.

Following evaluation it became apparent that to perform customisations on large scale and have them consistently performant another approach was needed.

The new approach

After some tinkering over a particularly wet weekend I had a eureka moment. The stapling approach was right, but what about setting up the page? Well thinking a little laterally it becomes obvious. The MySite personal is like any other site, go to the root and it picks up the default page url and loads it. Anyone familiar with Publishing features knows that these sites allow you to set the ‘welcome page’ of any site. This means that if you browse http://sp/ for example it works out to render http://sp/pages/default.aspx instead.

After a quick test using SPManager to set the welcome url to a different page my suspicions were confirmed. You can indeed change the default page and therefore point it to another page other than default.aspx. Armed with this knowledge lets look at how we can create a feature set to provision and apply the MySite customisation.

So the basic elements for customising the default page are the following:

• Feature to activate and add the relevant web parts. (covered in article six)
• Feature to provision the new aspx page.
• Feature to change the set the welcome page.
• Feature to staple the above to the MySite Personal template.

The basic solution structure

Lets create a new Farm solution and add the basic structure to it.

The CustomPage feature is responsible for provisioning the custom page to the site. The WelcomePage feature sets the welcome page to the custom page. The Stapler feature associates these features with the MySite Personal site definition. There is a module to provision the custom page, and finally the stapling elements to ensure these features gets activated against the MySite on creation.

The CustomPage feature

The CustomPage feature provisions the customised aspx page and includes the web part provisioning as required. If you’ve got complex requirements you may wish to create more features to activate the required web part features as dependencies.

So lets look at the elements:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="CustomPage" Path="CustomPage">
    <File Url="CustomPage.aspx">
    </File>
  </Module>
</Elements>

As you can see this simple elements provisions the custompage.aspx. If we were adding web parts to this custom page we’d add this to the all user web parts elements. For this article we’re not going to deal with this customisation. Although at this point it’s definitely worth mentioning the complexity if you want to keep the Shared and Personal documents views. As you’ll be aware these are provisioned from the Onet file and therefore it’s likely the list instances won’t exist when your stapled custom page feature fires. You’ll need to decide the best approach to provisioning list views from these ONET lists if you need them. As you’ll see in article six of this series we’re going to implement something quite different to the OOB so I’m not going to cover this now.

Another thing this feature is responsible for is activating the WelcomePage feature to set the page as the site welcome page. The reason we make this custompage feature responsible for it’s activation is that the welcome page property will throw an exception is the url is not resolvable.

[Guid("c61637c6-760f-4449-b997-08467930597f")]
    public class CustomPageEventReceiver : SPFeatureReceiver
    {
        #region Methods

/// <summary>
        /// Occurs after a Feature is activated.
        /// </summary>
        /// <param name="properties">An <see cref="T:Microsoft.SharePoint.SPFeatureReceiverProperties"/> object that represents the properties of the event.</param>
        public override void FeatureActivated(SPFeatureReceiverProperties properties)
        {
            base.FeatureActivated(properties);

SPWeb web = properties.Feature.Parent as SPWeb;

if (web != null)
            {

// Get the depended-upon Feature definition.
                SPFeatureDefinition featureDefinition = null;
                try
                {
                    featureDefinition = SPFarm.Local.FeatureDefinitions[new Guid("9e852c4f-93c4-401e-a947-968fa85fb985")];
                }
                catch (Exception ex)
                {
                    //Log here if you wanted
                    throw;
                }

web.Features.Add(featureDefinition.Id);
            }
        }

#endregion

}

The WelcomePage feature

The WelcomePage feature sets the web root folder welcome page. This is done via the feature receiver which contains the following code:

[Guid("8616b35f-efa6-4c69-9c2f-809e50fb99ef")]
    public class WelcomePageEventReceiver : SPFeatureReceiver
    {
        #region Constants

//The mycontent.apsx
        private const string CUSTOMPAGE = "custompage.aspx";

//The default.aspx
        private const string DEFAULTPAGE = "default.aspx";

#endregion

#region Methods

/// <summary>
        /// Occurs after a Feature is activated.
        /// </summary>
        /// <param name="properties">An <see cref="T:Microsoft.SharePoint.SPFeatureReceiverProperties"/> object that represents the properties of the event.</param>
        public override void FeatureActivated(SPFeatureReceiverProperties properties)
        {
            try
            {
                SPWeb web = properties.Feature.Parent as SPWeb;

if (web != null)
                {
                    SetDefaultPage(web, CUSTOMPAGE);
                }
            }
            catch (Exception ex)
            {
                //Do the logging here
                throw;
            }
        }

/// <summary>
        /// Occurs when a Feature is deactivated.
        /// </summary>
        /// <param name="properties">An <see cref="T:Microsoft.SharePoint.SPFeatureReceiverProperties"/> object that represents the properties of the event.</param>
        public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
        {
            try
            {
                SPWeb web = properties.Feature.Parent as SPWeb;

if (web != null)
                {
                    SetDefaultPage(web, DEFAULTPAGE);
                }
            }
            catch (Exception ex)
            {
                //Do the logging here
                throw;
            }
        }

/// <summary>
        /// Sets the default page.
        /// </summary>
        /// <param name="web">The web.</param>
        /// <param name="page">The page.</param>
        protected virtual void SetDefaultPage(SPWeb web, string page)
        {
            #region Guard

if (web == null)
            {
                throw new ArgumentException("Web was null");
            }

#endregion

SPFolder rootFolder = web.RootFolder;

rootFolder.WelcomePage = page;
            rootFolder.Update();

web.Update();
        }

#endregion
    }

This gives you an example of how to change the default page for the MySite personal. The code would need some embellishment to be production ready but gives you a good starting point.

The Stapling feature

The Stapling feature staples the CustomPage feature to the MySite Personal site definition to ensure that when new sites are created the custompage.aspx is provisioned and set page to the default page.

The elements looks like this:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <!– CustomPage –>
  <FeatureSiteTemplateAssociation Id="9dd6c130-4752-4ec7-910b-9b6be3cafb53" TemplateName="SPSPERS#0"/>
</Elements>

And that’s all there really is too it.

Before and after

Before the features are deployed the MySite created looks like the following:

It’s hosted under the standard url, which for example looks like ‘http://my/sites/administrator/default.aspx’.

After the Stapling feature is activated on the MySite web application the new MySites will change to our custom page. For the purposes of the example I’ve just dropped in a new paragraph of text. In reality you might make fundamental structural changes.

The major advantage is the light touch this approach makes. I’m a great believer that whenever customisations are made to SharePoint they should always leave you in a supportable and cleanable state. This approach leaves the OOB default.aspx alone and thus should you ever need to revert back to OOB you have that capability.

What’s next?

This article has laid some foundations to much deeper levels of customisation. It opens up structural as well as content changes as possible customisations. In the next article we’ll examine in more detail how to customise the blog feature for MySite to embellish the default blog site and how it gets created.