Wednesday, July 16, 2008

Getting that PDF Indexing to work in MOSS

Had a case where the latest Adobe IFilter had been installed, but the crawl log in MOSS was displaying "filtering process could not process this item" messages.

The key to fixing this issue was the information in this post from the Filter Center blog: checking the registry key value, and then adding the path to the Acrobat Reader folder were the solutions. With those in place, a full scan correctly indexed the PDF documents.

To save the search for the Adobe Acrobat PDF file icon logo for referencing in the DocIcons.xml file, here is the location of the GIF file on the Adobe site: http://www.adobe.com/misc/linking.html

Other useful aticles:

Tuesday, July 1, 2008

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.

Tuesday, June 17, 2008

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!

Monday, June 16, 2008

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!

Wednesday, May 28, 2008

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?

Tuesday, May 6, 2008

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.