Managing multiple master pages? RRS feed

  • Question

  • Greetings,

    I've been tasked with researching the best approach for managing multiple master pages in our SharePoint 2010 environment. We're a large company and have many departments which we've divided into site collections in the farm (currently talking 200+ site collections). We have a standard intranet corporate branding, but we're running into challenges where each site collection wants just a little something different on the master page - maybe different footer links, or they want their banner image to go to a different url which is acceptable by business web standards.

    We deploy our master pages as visual studio, wsp solution Features which are activated at the site collection level. When activated the features apply the master page and images etc... Does anyone have experience with the best way to manage master pages in this situation? Luckily we don't but it would be possible for us to have 200+ different master page solutions (if every dept. wanted something different) which would be impossible to manage. Any admin feedback or alternate branding approaches would be great.

    Wednesday, June 29, 2011 4:33 PM


  • Chris.  As regards the banner image you could just leave the control in the master page that displays the site logo from site settings but display the 'standard' image in the absence of that.  Users can then control the banner image from site settings, site logo as normal.

    If you have settings that need to be different for different web applications then you can use resources files and reference these from within your master pages.

    The example below tailors a sign in link

            <SharePoint:SPLinkButton runat="server" NavigateUrl="<%$Resources:mycompany, mycompanyloginurl%>" Text="Sign In">Sign In

    Beyond that I suspect that you are into writing your own custom controls to sit in the master page but take the configuration from the web site and then giving in the users away to tailor the links rendered by them.  I would have thought storing the actual configuration data in the web or site property bag not a bad way to go about it.


    Wednesday, June 29, 2011 4:48 PM