I have a custom page layout that I have designed using Visual Studio. Within it I have several web part zones and I have a zone where I would like users to be able to edit the properties of the web part within the Zone Template. Regardless of whether I add a custom web part or an out of the box SharePoint webpart to the zone template when you are in edit mode in the UI the drop down for the web part properties is missing and if you select the web part and use the ribbon all of the options are grayed out. This occurs in all browsers.

enter image description here

Here is what the zone is setup like:

<WebPartPages:WebPartZone runat="server" AllowPersonalization="true" AllowCustomization="true" AllowLayoutChange="false" FrameType="TitleBarOnly" ID="testWPZ">
                        Description="Description goes here"
                        Title="Site Additional Links"

        <WebPartPages:ContentEditorWebpart ID="testContentEditor" runat="server" webpart="true" AllowEdit="true" FrameState="Normal" ></WebPartPages:ContentEditorWebpart>

I don't know if I'm missing a property within the zone or maybe there's a setting for the page layout in the element xml that I am missing or need to have.

Here is the element xml for the page layout:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
     <Module Name="PulseSubSiteLandingPageNEAL" RootWebOnly="TRUE" Url="_catalogs/masterpage/pulsepagelayouts" Path="SubSiteLandingPageNEAL">
        <File Url="PulseSubsiteLandingPageNEAL.aspx" Type="GhostableInLibrary" ReplaceContent="TRUE" Level="Published">
             <Property Name="Title" Value="Title"/>
             <Property Name="FileLeafRef" Value="PulseSubsiteLandingPageNEAL.aspx"/>
             <Property Name="MasterPageDescription" Value="Description"/>
             <Property Name="UIVersion" Value="15"/>
             <Property Name="PublishingHidden" Value="FALSE"/>
             <Property Name="PublishingAssociatedContentType" Value=";#Pulse Subsite Landing Page;#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900E19C10C741B041E5A6E4BE278D2CEA29;#"/>
             <Property Name="HtmlDesignAssociated" Value="FALSE"/>
             <Property Name="ContentType" Value="$Resources:cmscore,contenttype_pagelayout_name;"/>
             <Property Name="_ModerationStatus" Value="0"/>
             <Property Name="FileDirRef" Value="_catalogs/masterpage"/>
             <Property Name="FSObjType" Value="0" />

I should mention as well that if I add either webpart manually using the UI to a web part zone I can get to the properties of the webpart.

Any help would be appreciated. Thanks.

1 Answer 1


After much research and crawling through the internet I came across this article:

There are many articles like this but in the beginning of the article it explains my issue quite succinctly:

Embed references to the web parts directly in the mark-up of the aspx page. The main problem with this approach is that once the page is deployed, the page is still “ghosted”. This means that the normal drop down to “Edit Web Part” is not shown, blocking future modifications to the page.

The two solutions to this problem seem to be either writing a feature receiver that updates, changes, removes webparts or adding the webpart definitions to the elements file.

The first solution works in most cases but you will run into problems if you change a page layout after assigning one. Since no code is fired you may not get the webparts you want when dynamically changing page layouts of the same content type.

The second solution will allow you to add webparts to the page that are editable but it comes with its own issues. When changing page layouts of the same content type you will get duplicate web parts on the page. Also, when making large modifications to the web part zones (or if different page layouts don't have the same web part zones) within the page layout the page will try to fix itself by moving webparts around to whatever webpart zones exist on the page, thus creating duplicates and putting webparts in places you don't want them. People have posted articles about running PowerShell scripts after deployments or changes to clean up the page layouts, which works in the case of reactivation but not when a user decides to dynamically change to a different page layout using the UI.

From what I've also read if you don't ghost the page layouts you can almost get the best of both worlds; adding webparts to the zones without duplication and the allowing of webpart editing. Sadly, it then presents a problem with certain page layouts not keeping up with the main page layout definition, since the file is no longer ghosted. Then when you go to update your page layout it will not always take on all page layouts currently being used.

In the end, to solve my problem I put fields in the page layout and then within the webparts I check for those fields on the page and override custom properties if those fields exist. Granted, this will only work if you only have one instance of the webpart on the page and could create problems if you plan on using the webpart across multiple type of page layouts, but for my current use case, this works for me.

Still, if someone knows a better way to accomplish this I'd love to see what it is.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.