This is the fifth article in a series which explores the SharePoint 2010 MySite features. This article will examines the default Blog creation and highlight changes required to customise this default.

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
  5. Customisation of a MySite Blog, how to alter the Blog – This Article
  6. The MySite centric intranet, putting the MySite at the centre of the universe

The challenge

 

By default the OOB MySite contains a web part which gives the user a quick prompt to create a personal blog on both the default.aspx and the persons profile page.

image

When clicked this will create a sub site based on the Blog site definition. It provisions a new blog site with some default data. So which approach do you take if you wanted to add additional functionality or change that default data for the blog site? The obvious answer would be to create the required features and staple these to the Blog site definition.

So assume we have several stapled features which replace the default content and make some additional tweaks to provision a client specific ‘enhanced’ blog. In theory when the user clicks the link to ‘Create Blog’ these features will get activated during site creation and all will be sorted.

You have to consider that stapled features can’t act upon anything being provisioned in the definition modules. If you examine the Blog site definition you’ll see that the lists and data are provisioned this way. So you need to take another approach to modify the data within provisioned lists. One approach would be to use the List provisioned or Site provisioned event handlers and put the logic there.

Well this works without error but the end result is not what you’d quite expect.

Unexpected results

 

So nothing unusual there, the blog created with no errors, works as it should and is still based on the OOB Blog site definition. But the custom data is not there and blog posts were not showing in the NewsFeed. Fearing something was fundamentally broken the investigation began. The following is the details about what’s going on in depths when the user clicks ‘Create Blog’

The fundamental problem was that when the user clicks this specific web part link it goes through some MySite specific logic to attach three event receivers to the Post list.

The ‘Microsoft.Office.Server.UserProfiles.BlogListEventReceiver’ needs to have the item added, updated and deleted events registered against the blog site Post list. This handler is responsible for generating the ActivityFeed change marker which drives the activity gathering event generation.

The OOB page contains the Microsoft.SharePoint.Portal.WebControls.BlogView web part. This web part checks for the existence of a property bag property of ‘urn:schemas.microsoft.com:sharepoint:portal:profile:blogwebid’ if this is not null or empty it renders the link for creating a new blog site. The generated url is something like ‘/_layouts/MySite.aspx?Blog=1’. As you can see this is pointing at the MySite aspx page but interesting has a query string value. This is the important part. Normally this page will simply check the existing user has a MySite and create one if not. With the query string value of ‘Blog=1’ it’s also instructed to generate a blog.

The logic basically checks the ‘urn:schemas.microsoft.com:sharepoint:portal:profile:blogwebid’ to see if a blog exists (will navigate to it if it did). If no value is set the the code will activate the ‘MySiteBlogs’ feature. This feature generates the site then sets the property. Once the site exists it will modify the list items adding the generic values. Final step is to associate the ‘Microsoft.Office.Server.UserProfiles.BlogListEventReceiver’ handlers.

With this knowledge in hand a quick addition to the custom blog stapling feature had them also attaching the missing handlers.

That fixes the missing Activity events but the data still appears to be wrong. During the execution of site creation the MySite.aspx modifies the data in the lists and replaces it with versions it chooses. The only 100% accurate way of stopping is to implement all this functionality in a page/handler yourself and adjust the blog web part link to point to your custom code instead.

What’s next?

 

So now we’ve seen some of the MySite specific extras for Blog sites. In the next article we’ll examine using the MySite functionality as the default homepage for an intranet.