Inconvienient SiteActions menu and hidding Publishing Actions

Hiding out of the box SharePoint parts has been made a whole lot easier in SharePoint 2010 with the introduction of the HideCustomAction element. So whenever you need or want to hide something in the Ribbon or the SiteActions menu you should look into that, instead of just deleting the controls from the masterpage (something you can only do for the SiteActions menu, and I strongly discourage you do to so and run back to the HideCustomAction). Thus after being asked to delete one of the options in the Site Actions (and encountering some issues after doing so) I spend some time digging into the Publishing options that you have in the Site Actions menu and the issues you could encounter there.

In my case we wanted to hide the ‘new page’ option that is available on publishing sites for people that didn’t have full control. So the option itself was allowed to stay there as long as only the Site Admins could see it. After searching around most of the posts and blogs pointed out that there where issues setting security to that specific control, so we settled to just disable it for everyone since we where running short on time. Hidding it for everyone looked pretty easy using the following snippet

<!-- Hide All Publishing Actions -->
<HideCustomAction 
    Id="HideCreatePublishingPage"
    GroupId="SiteActions"
    HideActionId="PublishingSiteActionsMenuCustomizer"
    Location="Microsoft.SharePoint.StandardMenu">
</HideCustomAction>

Everything looked clear at first; enabling our feature showed the menu to the left, and disabling our feature showed the menu to the right.

SiteActions example with feature enabled and disabled

Yet that’s where all the trouble came looking around the corner. It indeed did help us hiding the ‘new page’ option, until we started to experience some strange behavior in the out of the box functionality. If you used the ‘edit the page’ that is available even though you where on a Publishing Site did put the page in the editmode that is available on TeamSites. So instead of being able to edit the page and its metadata, the only option you would see was to add WebParts to the WebPartZones (if those are added to your page). As you can see editing the page with the feature disabled everything looked good while using it when the feature enabled results in the scenario on the right; a blank page that could not be added.

Edit page screenshot with feature enabled and disabled

So the next step was to modify the master page and change the link to something that works, since that is the place where the link is stored. However SharePoint resets the link from code behind with so it also requires you to set a custom ID to make sure the code behind does not override your link

<SharePoint:MenuItemTemplate runat="server" id="Custom_MenuItem_EditPage"
    Text="<%$Resources:wss,siteactions_editpage%>"
    Description="<%$Resources:wss,siteactions_editpagedescriptionv4%>"
    ImageUrl="/_layouts/images/ActionsEditPage.png"
    MenuGroupId="100"
    Sequence="110"
    ClientOnClickNavigateUrl="javascript:if (document.forms['aspnetForm']['MSOLayout_InDesignMode'] != null) document.forms['aspnetForm']['MSOLayout_InDesignMode'].value = 1;if (document.forms['aspnetForm']['MSOAuthoringConsole_FormContext'] != null) document.forms['aspnetForm']['MSOAuthoringConsole_FormContext'].value = 1;if (document.forms['aspnetForm']['MSOSPWebPartManager_DisplayModeName'] != null) document.forms['aspnetForm']['MSOSPWebPartManager_DisplayModeName'].value = 'Design';__doPostBack('ctl00$SiteActionsMenuMain$ctl00$wsaEditPage_CmsActionControl','switchToAuthoring');" />

That did fix the ‘edit page’ issue allowing us to edit the page, so we moved on with the project and all looked good. However somewhere in the test process we encountered an error that whenever a user has checked out a page, and an administrator was required to override the checkout a strange error appeared.

image

That lead me to dive a bit more into the issue and I found out that there are some settings done from the PublishingSiteActionsMenuCustomizer that are required to get everything to work properly in an Publishing Environement, so that’s where I stumbled upon a blogpost about hiding the site actions menu links so figuring it was worth a shot I did a quick test with it, and it indeed fixed all my problems, so I could revert the masterpage changes in the site actions menu, and it did fix my undo checkout issue.

That brought me back to the initial request, since I was modifying the control I could of course add some extra checks myself. For instance only show the ribbon button if someone has full control on the item (or site for that matter):

protected override void OnLoad(EventArgs e)
{
    // Retrieve current 'SiteActions menu'
    var menu = ToolBarMenuButton.GetMenuControl(this);

    menu.MenuControl.PreRender += (o, args) =>
    {
        var item = menu.GetMenuItem("wsaCreatePage");
        if (item == null || SPContext.Current.Web.DoesUserHavePermissions(SPBasePermissions.FullControl)) return;

        menu.MenuControl.HiddenMenuItems.Add(item);
    };
}

Now I am aware that we could use JavaScript to hide the buttons in the ribbon, but then again they still would be accessible by using JavaScript so that would be a no go.

So long story short; if you ever want to hide something in the publishing options you have in the SiteActions, make sure to test it on every possible scenario out there.

Leave a Reply