Hide the "View All Site Content" Quick Launch Link

To hide this link from all but those users with full control over a WSS site, open the site master page in SharePoint Designer and find the SPSecurityTrimmedControl element that contains a div with class ms-quicklaunchheader. The quickest route to this is to view the page in split view, and click on the "View All Site Content" link in the design pane.

The PermissionsString attribute of the SPSecurityTrimmedControl element determines what users can view this content. Change the value of this attribute to ManageWeb and only those users with rights to perform all admin tasks on the site will then be able to see the link on all pages in the site.

See this page for a list of all the possible permission string values.

WSS Search and Breadcrumb Links Fail over SSL

A site originally extended for extranet access needed to be now served over SSL, so I extended a new web application to enable this, and modified the external Alternate Access Mapping entry to be https rather than http.

The site was then successfully accessible on the internet, though I did notice that the full path had to be entered in the browser address bar, including the page name itself - for example, https://[siteurl]/default.aspx rather than just https://[siteurl].

Further testing revealed that the links in the breadcrumbs all led to a "Page cannot be diaplayed" IE error, and submitting a search on the site gave an error message on the results page that stated:

"If the URL should be serving existing content, the system administrator may need to add a new request url mapping to the intended application"

The cause was all in the AAM entry - I had a port number (80) in the extranet URLs from some early trials, and had not removed this port number when setting https. By setting the Extranet zone AAM internal URL and public URL to be simply https://[ssiteurl], these problems were solved.

Interesting that the pages were still accessible with an incorrect Access Mapping!

Double-check your hosting company's infrastructure

Story from the trenches today - a few weeks ago I customised a hosted WSS site, including UI changes and a small amount of functionality.

Somehow in one of the admin pages, the hosting company had exposed the capability to delete the complete site. So when my client did accidentally make use of that "feature", he called the hosting company to request a restore of the site.

Unfortunately, the hosting company discovered that they only actually have disaster recovery backup for an entire server farm. No application-level backup in place. It would take them 5 man days to retrieve the site.

Luckily, the site had not been used yet, so no data was lost. Just means that I have to rebuild from scratch... I had presumed that a hosted site would be safe, and so made no form of local backup.

So, in the words of Carl Franklin in Mondays (listen if you dare!), Things I have Learnt This Week:

• Check the recovery options offered by a hosting company
• Make your own backups of any customisations on hosted sites
• Write reminders for yourself of any tricky little changes to make a site work as required
• Take lots of screenshots

The latter point is worth reviewing. In this project I had taken a few screen shots of various pages within the site as development progressed, primarily to send to the client to show current state of play. Now I am using these screen shots to help recreate the site.

On the subject of screen shots. I use either Cropper or Faststone Capture for this task. Cropper is a free .net util, whereas Capture offers some nice easy image annotation options (plus ragged edges to images if required). Thoroughly recommend them both!

Site Definition Articles

Here's some articles to help me next time I'm creating MOSS and WSS Site Definitions:

• Creating an corporate intranet using MOSS
• MOSS 2007 Publishing web site definition template – onet.xml – syntax for properties and getting the right content types by Katrein De Graeve
• Custom Site Definitions in MOSS by Clinton Cherry

Site Definition Fails to Use My Custom Home Page

Here's a minor annoyance that doesn't causes any in-your-face error messages, but can lead to a few deep frowns.

A MOSS site created from my custom site definition failed to apply my custom master page to the default.aspx page. The MasterPageFile attribute in the default.aspx file in my Visual Studio project was certainly set to ~masterurl/custom.master, yet the deployed file in the associated SITETEMPLATES folder used the standard ~masterurl/default.master.

Turns out that I had missed an attribute from the node in the node within ONET.XML. What I had initially was
     Url="default.aspx" NavBarHome="true">
but what I needed was
     Url="default.aspx" Name="default.aspx" NavBarHome="true">

Yet the feature deployed, and the site was created. Could perhaps do with some "fail fast" philosophy in the implementation of some of these out-of-the-box operations rather than letting default values kick-in when there is a missing configuration value?

Override the Edit Form SaveButton - Part 1

An overview of how to override the action of the Save Button in a SharePoint form for a specific document library (in this case a Wiki library). The intention of this brief series of articles is to record how to add a custom behaviour to the Save button of a wiki edit form.

The elements in this solution can be all included in a single Visual Studio solution, but I suggest that they are compiled into several separate SharePoint features for ease of management/deployment. All the features can be referenced in a single Manifest.xml file.

1. Create a content type feature to define a custom content type for the document library. In the XmlDocument section of the ContentType definition, specify the name of a custom template for the edit form template:

    <XmlDocuments>
      <XmlDocument NamespaceURI="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms">
        <FormTemplates xmlns="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms">
          <Display>DocumentLibraryForm</Display>
          <Edit>MyCustomWikiEditForm</Edit>
          <New>WikiEditForm</New>
        </FormTemplates>
      </XmlDocument>
    </XmlDocuments>

The result of this will be that any library using this content type will display the custom content (to be created in later steps) on the edit form.

2. Create a user control file containing a new RenderingTemplate with the
template custom ID matching that in the custom content type.

To achieve this, create the new ascx file in the Visual Studio solution (as an example, I'll name it MyCustomWikiEditForm.ascx). Copy the Assembly and Register tags from the top of DefaultTemplates.ascx (located in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\CONTROLTEMPLATES).

Then find (in DefaultTemplates.ascx) the RenderingTemplate node for the template being replaced, and copy/paste this into the new ascx file - in this case, I would copy the complete RenderingTemplate with ID of WikiEditForm into my new ascx file. Rename the ID of the RenderingTemplate to match the custom ID from step 1 (i.e. to MyCustomWikiEditForm).

This new ASCX file will need to be deployed to the CONTROLTEMPLATES folder by stating the destination folder in a TemplateFiles node in the Manifest.xml for the solution, as in the following example snippet:

  <TemplateFiles>
    <TemplateFile Location="CONTROLTEMPLATES\MyCustomWikiEditForm.ascx" />
  </TemplateFiles>

In the next installment, I'll look at modifying the edit template to include a custom save button.

Whoops, Where are Those Site Themes Hiding?

I am trying to persuade the application pages in a WSS site to look similar to the site pages that are customised by a master page - my approach was to create a new theme, and modify the CSS in that theme using the CSS applied to the master page.

It almost worked, but had a nasty side-effect. Some part of the CSS caused the "select theme" list on the Site Theme admin page to be squashed out of screen space by the left-hand cells expanding too far across the page. The image of the still displayed, but there was no way to remove the bad theme.

Oh dear, what to do?

Then some playing in the IE Developer toolbar revealed a solution - the toolbar allows CSS styles to be edited and applied in the live page. I applied a width attribute to several of the cells in the affected table, and managed to reveal the theme list box in the displayed page, thereby allowing me to reapply the default theme before modifying the new theme.

This difficulty in modifying the application pages to match the site pages is an oft-quoted citicism of SharePoint. During a little research for this post, I have noticed that Microsoft has published a KB article on their recommended server-side fix for this.