Differences Between Publishing Layout Page & Web Part Page Classes

Ever wonder what the difference between the PublishingLayoutPage (


) class and the WebPartPage (


) class in SharePoint 2010 is? Let’s find out what we can.
First, let’s reference Microsoft’s declaration of both of these two classes.




Second, remember that the PublishingLayoutPage is only available with SharePoint Server 2010 and not in Foundation.
If you check out the WebPartPage class on MSDN, you can see that this class inherits from


, while when you check out the PublishingLayoutPage class, Microsoft just states that this is base class for all publishing layout pages. What does that mean? It has to inherit from something correct? Yes. As far as I can tell the PublishingLayoutPage class inherits from PublishingCachablePage class, and the PublishingCachablePage class inherits from the WebPartPage class. If you read the remarks of the PublishingCachablePage class at MSDN, and you will see that this class is used to re-enable caching that Foundation turns off. This allows our publishing pages to load faster. Nice huh? But since eventually the PublishingLayoutPage class is inheriting, through a few steps, from the WebPartPage class, what is the major difference to the developer? Let’s keep investigating.
Next, look at the members of the two classes in question. Notice anything? They appear almost exactly the same. They both expose the same Properties, Methods and Events. The only difference we can truly see is that the


method in the PublishingLayoutPage class assigns the master page to either the custom or default master page, which we already knew was the case with Publishing Layout Pages. You cannot set the masterpagefile property in the @Page declaration in Publishing Layout Pages.
Since these two classes look the same, does that mean that they can be used interchangeably? Sorry, no luck there, but that isn’t quite true either. If you create a Publishing Layout Page, by default, you will have a page declaration similar to:

<%@ Page language="C#"   Inherits="Microsoft.SharePoint.Publishing.PublishingLayoutPage,Microsoft.SharePoint.Publishing,Version=,Culture=neutral,PublicKeyToken=71e9bce111e9429c" meta:webpartpageexpansion="full" meta:progid="SharePoint.WebPartPage.Document" %>

What if you replaced the Inherits property to the webpartpage class:

<%@ Page language="C#" Inherits="Microsoft.SharePoint.WebPartPages.WebPartPage,Microsoft.SharePoint,Version=,Culture=neutral,PublicKeyToken=71e9bce111e9429c" meta:progid="SharePoint.WebPartPage.Document" meta:webpartpageexpansion="full" %>

What happens? Can this layout in the _catalogs/masterpage directory, which has been assigned as a “Page Layout Content Types”, be used as the layout for a new page in a publishing site? Well, yes, it can. Amazing, but wait. The catch is that if a new page is assigned to a use a layout page, but that layout page does not inherit from the PublishingLayoutPage (or your own class that itself inherits from the PublishingLayoutPage), then in the ribbon you will be unable to change the layout of this new page later on. Basically the Edit Ribbon for this new page will be the ribbon found on any webpart page, not the ribbon found on the Publishing Layout Page. Makes sense, but it’s worth noting.
What this means is that if you want to create a custom layout page for your publishing site, but you need to assign a unique master page to just that one layout page, then you “could” modify the @Page declaration to inherit from the WebpartPage class and then add the masterpagefile property. You can now assign this layout to content pages, just be aware that you will lose some of the functionality in the content page’s ribbon.
Let’s look at an example.
First, I created a page layout and named it PageLayoutTemplateCustom.aspx and placed it in the _catalogs/masterpage directory. Then by editing it’s properties, I verified the Content Type as “Page Layout” and the Associated Content Type as “Page Layout Content Types”. I saved, checked in and approved this Layout.


Next I created a test new page, test1.aspx, and once the page loaded, I clicked on Edit and set the Page Layout to my Custom General Layout. Save and publish and that worked as expected. My custom master page (I assigned the nightandday.master as my “custom” master) was applied to this new page.


Now, in SPD, I checked out and opened the PageLayoutTemplateCustom.aspx page layout and modified the @Page declaration so that it would inherit from the WebPartPage class, as well as assigned a masterpagefile value as /_catalogs/masterpage/v4.master (which in my case was not the default or custom master page). After I saved and eventually approved this layout file and reloaded the test1.aspx page, the master page changed, but the ribbon is now different. I no longer can change the page layout for this page. Good and bad. I can still edit the PageLayoutTemplateCustom.aspx file as needed to continually update the layout of pages that use this layout, I just cannot change the page layout of pages that have been assigned to use the PageLayoutTemplateCustom Page Layout.

Have you had experience with this and have more information to share? Please tell me so we can discuss.

2 thoughts on “Differences Between Publishing Layout Page & Web Part Page Classes

  1. […] class use. You can read more about this in an article I wrote a little while ago (https://blog.pixelmill.comm/786/sharepoint-2010-differences-between-the-publishinglayoutpage-and-webpa…).  This is rather important in Publishing sites, or Foundation sites with Publishing enabled. Let […]

  2. Will November 20, 2015

    This is great information. Wanted to update our home page with a new MasterPage, but didn’t want to deploy it over the entire site.
    Creating a PageLayout using the WebPartPage class did the trick.
    This works on MOSS 2007, as well, in case anyone was wondering.
    Thanks for sharing!!!

Leave a Comment

Your email address will not be published. Required fields are marked *

Enter Code *

Filed Under


Do you need to build a custom search-driven component for your #digitalworkspace while saving thousands of hours of development time?

Join us on as we lift the hood of #PnP Modern Search v4, show you how it's built, & take you on a live coding adventure.


#Hybridwork is more than just a buzzword to latch onto; it’s the future for many organizations for the unforeseeable future. So, how can you use #Microsoft365 for #hybridwork? Let's breaks it down…


It's that time again! Join the #PixelMillWebinars on 4/29 where @EricOverfield lifts the hood of #PnP Modern Search v4, shows how it's built, & takes you on a live coding adventure to customizing your own web part using the power of the existing codebase.


What? Anchor links now work in #SharePoint site navigation! This fix snuck in and I completely missed it. Use them to create a TOC for long pages or cross link between pages. They work in text or quick links web parts & nav too! https://support.microsoft.com/en-us/office/create-and-use-modern-pages-on-a-sharepoint-site-b3d46deb-27a6-4b1e-87b8-df851e503dec#bkmk_pageanchors

A big thank you to David Leveille and @CrushNetworks for having our President + Co-Founder @EricOverfield on this episode of #TheVirtualWaterCooler!

Subscribe to PixelMill's

* indicates required

Let's Talk Digital
Workspaces Today

Get In Touch