Web Parts in content with Master Pages without the form tag? No problem!

Form runat=server tag in a Master Page striked through
Removing the form runat=server tag from the Master Page is one of the ways to optimize Internet-facing websites built on the SharePoint 2010 platform. Unfortunately it also means losing some functionality such as Web Parts in content. Find out how to combine minimal Master Page markup with Web Parts in content.

Web Parts in content

SharePoint 2010 allows us to add Web Parts in content. Using this new capability we can create richer experiences without quirky workarounds. It allows us to combine content with applications and rich media – something that wasn’t possible in MOSS 2007, at least not without some custom development or difficult to manage pages.

Form runat=server: needed or not

SharePoint 2010 is a rich platform that allows you to quickly create solutions by using the standard building blocks. For this to work however there are some requirements that you have to fulfill, like having a form runat=server tag and certain Content Place Holders on your pages. Although those components are not always required, removing them can lead to breaking some of the standard functionality that relies on them.

Although controlling the output of Content Place Holder is rather easy to do, getting the grip on the form runat=server is more complex. As soon as you put the form runat=server tag on your page both SharePoint and ASP.NET will start adding markup and resources to your page. To compare the impact of adding the form runat=server tag to your pages I conducted a test using a sample website I am working now.

Without the form runat=server tag the page had the following characteristics:

  • Page size: 1.6KB
  • Total number of requests: 14
  • Total payload: 291.2KB

After adding the form runat=server tag to the Master Page the values changed as follows:

  • Page size: 4.4KB
  • Total number of requests: 18
  • Total payload: 388KB

As you can see only putting the form runat=server tag on the Master Page adds additional 4 requests and +90KB of data that to go over the line. The worst part is that you might not even use any of it!

Unfortunately removing the form runat=server tag and keeping things working is nothing but easy and in some scenarios, depending very much on your solution, it might not even be an option that you could consider. The moment you remove the form runat=server things will stop working. You won’t be able to rely on the ViewState in your custom controls, ASP.NET input controls will not work anymore and from the SharePoint perspective one of the first things that you will notice breaking are Web Parts in content. So is it really worth the effort? Well, that depends a lot on your requirements.

Web Parts in content without form runat=server

Web Parts in content are one of the things that break as soon as you remove the form runat=server from your pages. Although the Web Parts will be displayed on the page, they will be displayed in the first Web Part Zone available on the page instead in content where you placed them.

The reason for this is the mechanics behind the Web Parts in content capability. During the page execution process, the WebPartPage class emits a hidden Web Part Zone called wpz which holds all Web Parts placed in content. All Web Parts placed in content are initially executed in that Web Part Zone and are later moved to the right places in content. While instantiating the wpz Web Part Zone the WebPartPage class checks if there is form runat=server on the page. If none is found, the hidden Web Part Zone will not be instantiated causing Web Parts placed in content to be rendered elsewhere on the page. The good news is that you can make Web Parts in content work again even without using the form runat=server tag.

The following code snippet contains a control that fixes the problem of Web Parts in content being rendered outside the content:

using System;  
using System.Web.UI;  
using System.Web.UI.WebControls.WebParts;

namespace Mavention.SharePoint.Controls {  
    public class WpzEmitControl : Control {
        protected override void OnInit(EventArgs e) {

        protected override void CreateChildControls() {

            Microsoft.SharePoint.WebPartPages.WebPartZone webPartZone = new Microsoft.SharePoint.WebPartPages.WebPartZone {
                ID = "wpz",
                PartChromeType = PartChromeType.None,
                AllowLayoutChange = false


            ChildControlsCreated = true;

        protected override void Render(HtmlTextWriter writer) {

What this control does is to instantiate a new Web Part Zone called wpz. To prevent the Web Parts from being rendered twice, the control suppresses its rendering process by overriding the Render method without implementing it.

Once you have the control in place all that’s left is to add this control to your Master Page and Web Parts placed in content should be rendered correctly just as you would expect them to.


Optimizing Web Content Management solutions built on the SharePoint 2010 platform is a complex task. One of the approaches to minimize the number of requests and the overall payload is to remove the form runat=server tag. Unfortunately it’s not an easy decision to make as it introduces a number of serious consequences that you should be aware of. One of such issues is breaking the rendering of Web Parts placed in content. Luckily it can be fixed using a simple control placed on the Master Page.


comments powered by Disqus