This is the second article in a six-part series on ASP.NET Master Pages and SharePoint.
Previously in Introduction to Master Pages we discussed master pages in relation to general ASP.NET. Now that we have a generally understanding of how master pages work, we can discuss how SharePoint has implemented them. This article will discuss the out of the box master pages in SharePoint in order to gain an understanding of how SharePoint customized the out of the box site. These same techniques will be used to build our own, customized SharePoint sites.
In the previous article we described master pages and content pages. Content pages contain a reference to the master page to determine the place holders to fill in. In an ASP.NET application the master page can live on the file system so a direct reference can be made to a physical file on the system. This same concept is possible in SharePoint; however that wouldn’t take advantage of the natural SharePoint structure.
SharePoint is based on lists/libraries. These are galleries in which multiple instances of particular information can be added. The basic example of these is the document library. You can upload multiple documents, edit individual documents, change metadata about documents, etc… Lists/libraries give SharePoint users access to information directly in the comfortable SharePoint webpage. The advantages of this are that if you need to add a new item to a list/library you don’t have to ask a developer to do it (like a typical ASP.NET application).
SharePoint master pages have their own list/library called the Master Page Gallery. This is a location on the site where a site administrator can access and modify SharePoint master pages. To access a SharePoint master page gallery go to a SharePoint site collection, go to the Site Settings, then click on the master page gallery.
The advantage of storing master pages in the SharePoint master page gallery is that you have easy access to the master pages (even after the site has been deployed). You can make your changes to the master page and then upload it to the master page gallery when you are finished. If your content page already points to that master page, the end user will see your master page changes as soon as the newly edited master page is checked in.
SharePoint is built on a template structure. These templates are referred to as Site Definitions. You might also hear the term Site Template, however that is a customization of a site definition - thus it is still built on the same principles.
Site definitions contain the pages you see on the SharePoint site with sections that can be modified. A good example of this is when you choose to create a team site in SharePoint.
When you choose to create a team site you are choosing to create a site based off the team site definition. This site definition determines the pages that show in the site (for example: the default.aspx page) and the initial content to fill the site in with.
The page that gets created in the site definition (for example: default.aspx), is a content page. In the first part of this series (Introduction to Master Pages) we discussed how content pages refer to a master page. Thus, the out of the box content pages, within the SharePoint site definitions, have references to the master pages in the master page gallery.
Previously I mentioned that the SharePoint content pages refer to master pages from the SharePoint gallery. This would lead one to assume that there is a hard coded path, to the master page, from the content page.
However, if this is a hard coded path to the master page, then it can never be changed without modifying the actual content page. But, SharePoint provides a way for the administrator of a site to switch the master page through the UI.
This is a MOSS publishing feature, which is not available on WSS or a standard MOSS site. However the underlying architecture is the same in every version (they just didn’t give the user the ability to see this screen in WSS and standard MOSS).
So, how does SharePoint accomplish this architecture? SharePoint has a master page token replacement functionality that runs when you view a site.
There are 3 tokens available for SharePoint master page references:
So, what is the difference between dynamic tokens and static tokens?
Static Token - direct reference to a master page. If your aspx page is at http://mysitecollname/mysitename/default.aspx and your static token is ~sitecollection/mymaster.master, then your master page file has to live at http://mysitecollname/mymaster.master. Or, if you static token is ~site/mymaster.master then your master page has to live at http://mysitecollname/myysitename/mymaster.master.
Dynamic Token - replacement reference to a master page. This means that SharePoint will replace this string with the real reference to the master page when the screen renders. Basically there are two settings for every site called MasterURL and CustomMasterURL. MasterURL maps to “System Master Page” in the screenshot above. And, CustomMasterURL maps to “Site Master Page” in the screenshot above. If SharePoint sees ~masterurl/default.master in your content page, then it replaces it with whatever is in the MasterURL property. If SharePoint sees ~masterurl/custom.master in your content page, then it replaces it with whatever is in the CustomMasterUrl property.
The Dynamic Token architecture allows SharePoint to replace the master page reference at run time. Thus, SharePoint has the flexibility of providing UI screens for the end users to replace the master pages (even though they only provide this UI on MOSS publishing pages). This functionality is also available through code for any version of SharePoint. So, developers can do this programmatically if necessary too.
Example from SharePoint’s team site definition:
<%@ Page language=”C#” MasterPageFile=”~masterurl/default.master” Inherits=”Microsoft.SharePoint.WebPartPages.WebPartPage,Microsoft.SharePoint,…
There are 3 main types of Master Pages in SharePoint:
Site master pages are usually used in SharePoint publishing site definitions, but they can be used for any SharePoint version. These pages are used so the main page can have one master page while the subpages and views use other master pages (example of a subpage is a view of a list or library). This is needed for publishing pages because the main page, of a site or subsite, usually has the publishing feature turned on while the other pages don’t. These publishing UI functionalities are contained in the master page, thus you need a separation of master pages between the main page and the subpages.
This technique is not specific to publishing pages. A good example of this is the meeting workspace site in MOSS. This site definition is not a publishing site. However the main page is different than the subpages. This is accomplished by making the main page a site master page.
Site master pages are defined by ~masterurl/custom.master in the content page declaration.
System master pages are used for most non-publishing sites and subpages in publishing sites. The system master page is what you typically see when you go to a WSS site or a non-publishing MOSS site.
System master pages are defined by ~masterurl/default.master in the content page declaration.
Application master pages are for all “Layout” pages. Layout pages are SharePoint administrative pages that are typically seen when doing site administration. You can tell a layout page because the URL of the site has _layout in it. Layout pages are static, file server pages that are not driven by the database like other pages in SharePoint. We will discuss application pages in more detail in article 5 of this series because of the difficulties involved in understanding and customizing them.
Application master pages can be found at: %Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS.
In order to get an understanding of how SharePoint implements its master pages, we are going to examine the default.master page. This is the master page used for the typical “out of the box” SharePoint site. The default.master can be found at %Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\GLOBAL. When a new SharePoint site is created, this master page is moved from this 12 hive path to the master page gallery of the newly created site. Actually, “moved” is not the appropriate word. In fact, SharePoint just keeps a reference in the master page gallery to the file on the 12 hive path. This is a concept called Ghosting or Un-customizing.
Now that we understand how SharePoint deals with the default.master page, we can look at what the default.master page contains. This master page contains what any other master page would contain - html and ContentPlaceHolders.
The html in the default.master contains things such as:
All of the out of the box pages in SharePoint, know how to deal with the ContentPlaceHolders from the default.master page. That is a hint for anyone thinking about how they can customize master pages - you want to use the same ContentPlaceHolders that the default.master contains.
The publishing site is a MOSS feature that allows the SharePoint site to act more like an Extranet or Internet (rather than just an Intranet). While a publishing site is not needed to create an Extranet or Intranet, it provides a lot of functionality to make the process easier. One of these functionalities is the ability to switch the master page from the UI.
Another one of these functionalities is that SharePoint provides more master pages in the master page gallery. These are out of the box master pages that make a SharePoint site look more customized.
This is customization tip #1: for a quick way to make a SharePoint site look “less like SharePoint” create your site as a publishing site and pick one of the “extra” master pages provided for publishing sites.
The out of the box master pages for publishing sites can be found at %Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\PublishingLayouts\MasterPages. Just like the default.master, these master pages are moved to the master page gallery of the SharePoint site when the publishing site is created. Once again, just like default.master, the word “moved” is actually incorrect because SharePoint technically keeps a reference to the master page on the 12 hive file system (the concept called Ghosting or Un-Customizing).
Actually, these get moved to the master page gallery when the publishing feature of the SharePoint site is activated. But, the publishing feature is activated when a publishing site is created, so it is appropriate to say the publishing master pages get moved to the master page gallery when a publishing site is created.
You might think that you can just modify the default.master from the 12 hive, or one of the publishing master pages, in order to customize a SharePoint master page. However, this is not recommended best practice. The reason for this is Microsoft could put out a patch for SharePoint that replaces the out of the box master pages, thus overwriting your changes.
However, you can modify the master pages by going to SharePoint designer and making your customizations there. You might ask “why can I do this in SharePoint designer and not to the file directly”? The reason is SharePoint designer UnGhosts or Customizes a page. Unghosting, or customizing, is the process SharePoint takes to break the reference to the physical file and makes a virtual copy of that file for you to use directly within your SharePoint site. This is good practice for quick changes. However, this forces you to code directly against a site, rather than wrapping it up in a good solution (which should be done for development efforts in order to keep things deployable).
Thus, if you are not in a situation where you can make a change to the master page directly against the site (i.e.: SharePoint Designer), then the process for customizing master pages is to create your own master page and upload it to the master page gallery. Then re-point the master page reference on the SharePoint page to your new master page. This concept will be demonstrated in the following articles in this series.
I am currently a Project Manager at RDA Corporation (don’t worry – PMs at RDA do a lot of architectural work too). In addition I am also the IW/Collaboration Evangelist Team Leader at RDA. The IW/Collaboration Evangelist Team at RDA is dedicated to the growth and knowledge of SharePoint and other collaboration tools within Microsoft. I have been working with SharePoint since 2001 and have been involved in numerous custom application efforts centered around SharePoint during my employment at RDA. I have been coding in .net since it came out and am Microsoft Certified – MCPD, MCSD, MCAD, MTS (SQL Server 2005), MTS(SharePoint).
Contact the author | Other Posts by ggalipeau (6) | Author's Website
Loading ...
