Differences Between Publishing Layout Page & Web Part Page Classes

Ever wonder what the difference between the PublishingLayoutPage (

1
Microsoft.SharePoint.Publishing.PublishingLayoutPage

) class and the WebPartPage (

1
Microsoft.SharePoint.WebPartPages.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.

1
Microsoft.SharePoint.Publishing.PublishingLayoutPage

http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.publishing.publishinglayoutpage.aspx

1
Microsoft.SharePoint.WebPartPages.WebPartPage

http://msdn.microsoft.com/EN-US/library/microsoft.sharepoint.webpartpages.webpartpage
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

1
System.Web.UI.Page

, 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

1
OnPreInit

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=14.0.0.0,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=14.0.0.0,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

    Awesome!
    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

Related

Anyone who has 'attended' a physical meeting by 'conferencing in' in knows the frustrations & limitations that come from not being in the room. You're the voice in the ceiling & not equally represented in the conversation.

This is no longer acceptable.

http://ow.ly/EmFK50Fqqhu

Today, we find ourselves facing the “hybrid work paradox.”

Employees are keen to retain flexibility. At the same time, human-to-human collaboration remains important.

To marry the best of both, hone your strategy, spaces, & tech to suit employee needs.

http://ow.ly/JtVO50Fn8qX

It's the day of the show, y'all!

Join the #PixelMillWebinars this morning at 11am PST for a live panel discussion about what the #digitalworkspace looks like for a #hybrid team, & how #Microsoft365 can empower your users no matter where they're working.

http://ow.ly/q81i50FhITy

IT'S WEBINAR WEEK!

Join the #PixelMillWebinars this Thursday as we welcome key players from @OrchestrySoft, @KieferConsult, and @AP_Mortgage to discuss the hybrid work paradox and how #Microsoft365 can empower your users no matter where they're working.

http://ow.ly/2uc550FfqO6

We've all been itching to get "back to normal," but what does that mean? Are we missing out on valuable lessons learned by trying to return to something that perhaps wasn't working before?

Join us next week for a live panel discussion on the new normal.

http://ow.ly/CfsU50FdQXv

Subscribe to PixelMill's
E-news

* indicates required

Let's Talk Digital
Workspaces Today

Get In Touch