Best Approach To Activate MasterPage for SharePoint Web

Company | Articles & Research | Services | Software |

Our Company

All SharePoint Articles

Security

Development

Accounting / Dynamics

AIS / Dynamics GP

Other

Consulting Services

Freeware / Experiments

Applications	WebParts	Security Components
SharePoint Field Diff And Copy Utility * Written In January, 2012 SharePoint Security Scanner * Written In January, 2012 SharePoint Kerberos Buddy * Written In Feburary, 2011 BioPoint: SharePoint Biometric Authentication * Written In September, 2007 SharePoint List Security Migrator * Written In August, 2007 SharePoint Anti-Keylogger™ * Written In April, 2006 S.M.A.R.T SharePoint™ * Written In May, 2006 SharePoint Sentinel™ * Written In June, 2006 SharePoint Scrubber™ * Written In July, 2006 SharePoint Safeguard™ * Written In August, 2006	SecureSilverlight For SharePoint * Written In January, 2010 Simple Rollup WebPart For SharePoint * Written In Novemember, 2009 SimpleChart For SharePoint * Written In December, 2009 SimpleSecurity For SharePoint * Written In June, 2009 CrytoCollaboration (Encryption) * Written In June, 2007 Sample AJAX Rotator WebPart * Written In July, 2007 Sample SharePoint Redirector WebPart * Written In August, 2006 WFE Server Name WebPart * Written In January, 2006	PDF IRM Protector * Written In December, 2010 ADAM Role Provider * Written In February, 2007 Universal Provider Framework * Written In April, 2007

Contact

Best Approach To Activate MasterPage for SharePoint Web

Going through a quarterly code review with a company today, we started to talk about the “best” way that a masterpage should be programmatically activated for a particular SharePoint web as the way being used by some components was fairly poor.

Below is what we decided on, which I don’t know how I feel about. I am leaving a lot of the exception handling out for brevity.

Firstly, the GenericMasterPage super class inherits from the SPFeatureReceiver concrete class, implementing all the obligatory abstract inherited members. This just contains references to the static application methods in the Builders class.

PLAIN TEXT

C#:

public class GenericMasterPage : SPFeatureReceiver
{
public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
Builders.IterateGalleryAndApplyTemplate(properties, Constants.GENERIC_MASTER_PAGE_NAME);
}
public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
{
Builders.IterateGalleryAndApplyTemplate(properties, Constants.DEFAULT_MASTER_PAGE_NAME);
}
#region Unused Abstract Inherited Members
public override void FeatureInstalled(SPFeatureReceiverProperties properties)
{
// This abstract inherited member requires no behavior modification
}
public override void FeatureUninstalling(SPFeatureReceiverProperties properties)
{
// This abstract inherited member requires no behavior modification
}
#endregion
}

Following, the Constants class, as the name implies, defines constants!

PLAIN TEXT

C#:

public class Constants
{
public const string DEFAULT_MASTER_PAGE_NAME = "default.master";
public const string GALLERY_LIBRARY_NAME = "Master Page Gallery";
public const string GENERIC_MASTER_PAGE_NAME = "lps.master";
public const string PROPERTY_TO_QUERY = "Name";
public const string MASTER_REL_LINK = "_catalogs/masterpage/";
}

Lastly, the Builders class contains the static IterateGalleryAndApplyTemplate method which will use a LINQ query to ensure that the master page to apply is available, and then apply it to the current SharePoint web.

PLAIN TEXT

C#:

public class Builders
{
public static void IterateGalleryAndApplyTemplate(SPFeatureReceiverProperties properties, string templateName)
{
SPSecurity.RunWithElevatedPrivileges(() =>
{
using (var web = (SPWeb) properties.Feature.Parent)
{
web.AllowUnsafeUpdates = true;
var ensureExistance = SPContext.Current.Web.Lists[Constants.GALLERY_LIBRARY_NAME].Items.Cast<SPListItem>().
Where(item => Equals(item[Constants.PROPERTY_TO_QUERY].ToString(), templateName)).FirstOrDefault();
if (ensureExistance != null)
{
string masterUrl = new Uri(web.Url).GetComponents(UriComponents.Path, UriFormat.Unescaped);
if (!masterUrl.StartsWith("/")) masterUrl = String.Format("/{0}", masterUrl);
if (!masterUrl.EndsWith("/")) masterUrl += "/";
masterUrl += Constants.MASTER_REL_LINK + templateName;
web.MasterUrl = masterUrl;
web.CustomMasterUrl = masterUrl;
}
web.Update();
web.AllowUnsafeUpdates = false;
}
});
}
}

I wonder if there is a more efficient way of achieving this same requirement.

Article Or Research Filed Under SharePoint Development.

2 Comments »

[...] Best Approach To Activate MasterPage for SharePoint Web [...]

Pingback by Links (9/27/2009 « Steve Pietrek – Everything SharePoint) — September 27, 2009 @ 5:23 pm
A few suggestions:
1) You shouldn’t dispose properties.Feature.Parent.
2) If a user has permissions to activate a feature, they will usually have permissions to change the master page – RWEP is redundant.
3) AllowUnsafeUpdates is only required if the code will execute on a GET – activating through the web is a POST.
4) Why use SPContext.Current when you already have web as a reference to the current site? This will break if the feature is activated from stsadm.
5) When you’re checking for existence you might want to support master pages that are provisioned in site collection’s root master page gallery as well.
6) I would probably move all the constants to feature properties so the receiver can be reused.

Cheers ~
Keith

Comment by Keith Dahlby — September 28, 2009 @ 8:15 am

RSS feed for comments on this post. TrackBack URL

Articles & Research

Latests SharePoint Development Posts

Latests SharePoint Security Posts

Best Approach To Activate MasterPage for SharePoint Web

2 Comments »

Leave a comment