Share via

How to Find the Menu Item You Want to Hide in SharePoint 2010

  • Article

Background Info

One of my customers has a lot of custom code that they have been porting from SharePoint 2007 to 2010. Among the code is a feature that simply replaces the “Delete Site” link in the Site Settings page for a web (i.e. a single website, rather than a site collection. SharePoint terms really make it difficult to talk about SharePoint solutions.)

The Good Bits

In my customer’s 2007 environment, they had a feature that hid the default “Delete Site” link using code similar to the following:

 <Elements xmlns="https://schemas.microsoft.com/sharepoint/">

     <HideCustomAction

         Id="CustomHideDeleteWeb"

         GroupId="SiteAdministration"

         HideActionId="DeleteWeb"

         Location="Microsoft.SharePoint.SiteSettings" />

 </Elements>

Using this code in SP2010, however, did not produce the desired effect. Unfortunately, searching for documentation online yielded no, or incorrect, information.

I’m going to put the link here, in hopes that it gets both fixed and updated soon.

https://msdn.microsoft.com/en-us/library/bb802730.aspx

Currently, I’m getting an error trying to access the link. My client claims that the information he was able to see on the page was identical to what was displayed for SP2007.

In any case, I’d already tried viewing the source of the Site Settings web page and searching for the “Delete Site” link. In so doing, I’d discovered a reference to a “DeleteWeb” Id. Assuming that this was the control Id for the “Delete Site” link, I again tried it in my test feature. But still, my attempt to replace the default “Delete Site” link was unsuccessful.

I won’t tell you what other things I tried—I was getting a bit desperate by this time—before finally putting out a call (well, an email) for help and alternate ideas. The next day a colleague of mine named Doug McCusker IM’d me offering to help.

Here’s what he showed me:

  1. Features are kept in the \Template\Features folder in the 14 hive (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\.) Fortunately for us—and by “us”, I mean SharePoint developers—even default “features” are kept here.
  2. In our case, this meant that we quickly found a folder titled SiteSettings.
  3. The SiteSettings folder contained two files:
  1. feature.xml
  2. SiteSettings.xml.

  • SiteSettings.xml is the one in which we’re interested because it describes the “custom controls” used on the Site Settings page.

    Note that in the previous sentence, I’ve put quotation marks around “custom controls”, at the risk of looking like one of those people that goes around using “air quotes” while speaking. The reason for this, however, is to point out that these controls—despite being OOB SharePoint—do actually customize the page, making it different from a standard SharePoint template-based page. Using this as an example, it stands to reason that we could probably find out the Ids of a lot of other “custom controls”.

Basically, what we find is that SharePoint OOB code is set up using the same mechanisms as developers like you or me would use to further customize it.

Back to the problem at hand: we searched through the SiteSettings.xml file for the previously-discovered “DeleteWeb” Id. What we found was that, as suspected, the “DeleteWeb” Id was still in use. What had changed, however, was the GroupId value! Rather than the 2007 value of “SiteAdministration”, the “Delete Site” link was now in a group called “SiteTasks”. Ah-HA!!

Going back to Visual Studio, I quickly altered the Elements.xml file I’d created to test all of this out so that the HideCustomAction element looked like this (note the line I’ve highlighted):

 <HideCustomAction

     Id="CustomHideDeleteWeb"

     GroupId="SiteTasks"

     HideActionId="DeleteWeb"

     Location="Microsoft.SharePoint.SiteSettings"/>

And voila! The default “Delete Site” link was gone from sight!

But wait! We wanted to replace the link, not just hide it!

Just in case you’re not familiar with replacing default controls (like me prior to this little project), here’s what else I discovered:

To replace a control, you have to hide the old control, then create and display a new one. Fortunately, the code for the second part was just about as easy as the first. Below my HideCustomAction node I added a CustomAction node. The bit of XML for this node looked as follows:

 <CustomAction

     Id="DeleteWeb2"

     Description="This is my special Delete Site link."

     Title="Delete Site in a Special Way"

     GroupId="SiteTasks"

     Location="Microsoft.SharePoint.SiteSettings"

     Sequence="40">

     <UrlAction Url="~site/_layouts/SPCustomAction/MyAppPage.aspx"/>

 </CustomAction>

Again noting the lines I’ve highlighted, the most important thing about the code above is this: the Id of the new CustomAction node has to be different than than the Id of the node that is being replaced. Otherwise, you just wind up hiding both links.

And there you go. After adding the code above, I redeployed my solution to my development environment and watched as my page rendered with—in place of the “Delete Site” link—my new link, “Delete Site in a Special Way”.