An HTML Programmer’s Guide to SharePoint Customization

Master Pages and Page Layouts

The master page is the base from which everything else is built. Every page on your site will use the same master page, so you'll want to hardcode only those HTML elements on the master page that are common to every page in your site, such as the header and footer. This is also where you reference any .NET components that will appear on every page on your site, such as navigation controls. Lastly, you'll add "holes," called "content placeholders," to your master page that the page layouts you write will fill in. Think of these content placeholders as the areas where the HTML changes from page to page. You can add any number of these placeholders throughout your master page and they can hold any size HTML. For example, you could have a small placeholder in the header that pulls in a different image from each of your page layouts, and a larger one below your header that allows each page layout to change the entire design and layout of the content area of your page. The code for content placeholders looks like this:

In the master page:

   <asp:ContentPlaceHolder id="PlaceHolderPageImage" runat="server">
      <img src="defaultimg.jpg" />
   </asp:ContentPlaceHolder>

In the page layout:

   <asp:Content ContentPlaceHolderID=" PlaceHolderPageImage " runat="server">
       <img src="Customimg.jpg" />                                
   </asp:Content>

How much HTML you put in the master page and how much you put in your page layouts depends on how much you want each page to differ from the master page. When you want a site that contains drastically different pages with varying numbers of columns and features, you'll want to put most of your HTML in the page layouts and include large content placeholders on your master page. In contrast, when you want every page to be very similar, you can put most of your HTML in the master page and leave your page layouts fairly slim.

So end users can customize the content on your pages, the page layouts themselves contain "holes" that are editable through the web browser. These holes consist of field controls or web part zones, and will look something like this:

Rich HTML Field:

   <PublishingWebControls:RichHtmlField id="TopTitleContent" 
   FieldName="PGPageTopContent" runat="server"/>

   <WebPartPages:WebPartZone runat="server" AllowPersonalization="false" 
   ID="RightZone" FrameType="None" Title="RightZone" Orientation="Vertical" />

While both field controls and web parts zones allow end users to enter content onto a page, they do that in very different ways. Field controls are .NET 2.0 controls with code that defines how content can be entered into that control. For example, a field control could limit a user's entry to a single line of unformatted text. Field controls are tied directly to the page, and cannot be changed or removed by the end user. Changes made to field controls can be rolled back using SharePoint's versioning features.

In contrast, a web part zone is a very open-ended content area that allows users to add any web part they'd like to include on the page. A web part is also a .NET control, and is similar to a field control. SharePoint comes with a number of web parts built-in. End users could choose to add any number of these web parts into any web part zone on a page, which provides a great deal of flexibility. However, a drawback to web parts is that they are not tied to the page itself, so changes made to them cannot be rolled back using SharePoint's versioning features the way field controls can be.

It's important to remember that any HTML you include on the page layout outside of these "holes" will not be editable by end users. In other words, your page layout acts like a template, defining the number of columns and the general purpose and design of the page, while still letting users define the exact content on the page.

You could have a page layout for a 2-column overview page and a different one for a 3-column detail page. You could also have a specific page layout for each department, letting each have a unique header and design, while still retaining the common features you've put in the master page across multiple departments. If you wanted to, you could create one large Rich HTML Field on your page layout and allow end users to define all the HTML within that area. You have complete control over how you organize the HTML and who has control over which pieces of content.

To help you decide how much to include in the master page and page layouts, and how much freedom to give your end users, here are some questions you should answer before starting to develop your master page and page layouts:

1. How much control do I want my end users to have over the page's design? Which areas of content should be editable by end users, and how will they edit those areas (web parts or field controls)?
2. How much HTML markup can I put in the master page vs. the page layouts to help with maintainability and consistency?

Note that the field controls available to your pages depends on the content type you choose for your page layout Every component in SharePoint (including master pages, page layouts, lists, documents, folders, pages, etc.) is based on a specific content type. Similarly, each content type inherits from a parent content type. All content types ultimately inherit from the System content type. You can use the Site Content Type Gallery to view many of these content types.

You use three default content types to build a page layout: Article Page, Redirect Page, and Welcome Page. All three inherit from the base Page content type. Most page layouts on a publishing site are built from the Welcome Page content type. . SharePoint's default Page Content Type comes with a couple of different field controls that allow end users to add content to a page. If you need more field controls than are available by default, you can create a custom content type that inherits from the Page or Welcome Page Content Types. However, you can add as many web part zones as you'd like to a page layout. For example, you can use the Content Editor Web Part as a substitute for the Rich HTML Field Control, if you aren't concerned about content versioning or reusable content and don't mind your users being able to swap out web parts.