2

Is it possible to apply a custom master page and theme to a site from the layouts folder instead of provisioning them down to the site with a feature? I'd use code and a feature receiver, but not sure what the code would look like.

3

You can assign a master page in the layouts folder programmatically to a site (SPWeb).

In PowerShell it would look something like:

$site = Get-SPSite "http://yoursitecollection"
foreach ($web in $site.AllWebs)
{
    $web.MasterUrl = "/_layouts/15/yourfolder/themaster.master"
    $web.CustomMasterUrl = "/_layouts/15/yourfolder/themaster.master"
    $web.Update()
    if ($web.ID -ne $site.RootWeb.ID)
    {
        $web.Dispose()
    }
}
$site.Dispose()

Ideally though you would develop the master page into a feature with a feature receiver to apply the master page on activation, and revert the master page on deactivation.

  • Can the same be done with an spcolor file? – user22059 Feb 3 '14 at 16:22
  • Never tried it. – RJ Cuthbertson Feb 3 '14 at 19:01
3

Your custom master page should NOT be residing in LAYOUTS directories, but instead to inside of a custom feature destined to "GhostableInLibrary". The reason being the performance and the fact that file itself will not be stored in the content database, and hence SharePoint will continue to use a cached copy of the file from the file system until it has been customized. Having a Ghosted master will definitely improve performance. Please refer to the starter solution to deploy your master page branding solution with feature receiver.

  • You can also use PowerShell if you intend to do it for all the site collections within a web application (provided feature has deployed the master page) gallery.technet.microsoft.com/Set-custom-pages-to-all-d6d66dc5 – Falak Mahmood Feb 2 '14 at 2:30
  • When you say "improve performance", are those Microsoft's words? I'm weighing the options. To me, one less feature means a thousand less headaches. And having a single copy of the master page on the file system is easier to maintain. But if the official line from Microsoft is "No, dont do that"... etc – user22059 Feb 3 '14 at 16:21
  • Let's take an example, When a site is created so SharePoint doesn’t really copy the master pages like V4.master/Oslo.master into a new database table or directory. These files exist only once on each of the front end web servers and SharePoint just reference them to create a new site. The result is that site appears to have it’s own pages but in reality they are shared across all sites that use that site definition. This technique is called ghosting and improves performance as SharePoint and you can't achieve the same while deploying your master page into the layouts folder. – Falak Mahmood Feb 3 '14 at 17:28
  • Think about it: you will NOT get any versioning or approval workflows for the master page, and files deployed to LAYOUTS folder will be available to everywhere in SharePoint farm including central admin, SharePoint Service Provider and what not! – Falak Mahmood Feb 3 '14 at 17:32
  • 1
    Thanks. But to be fair, devil's advocate would argue for more SharePoint. My experience is that SharePoint is awful. There's time-consuming, there's the event horizon of a black hole, and then there's coding in SharePoint. IIS resets, absent documentation and nonsense errors. 2 minute tasks become life sentences. If I can avoid it, it's hard not to. Even a simple provisioning feature will somehow find a way to be way more trouble than its worth. Unless it affects the user in some way, then there's something to consider. It sounds like both solutions are similar but for us no access is a bonus – user22059 Feb 3 '14 at 20:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.