Missing document icons from search results with FAST for SharePoint

There’s a defect whereby your search results in SharePoint will not have document icons if you’re using FAST for SharePoint.

This will happen to you, whenever you’re using a Document Library created from a custom Document Library template (i.e. Type != 101).

Why this happens

The problem is that the contentclass of documents from custom libraries indexed by FAST in is not compatible with the way the Core Results Web Part determines which icon to display. Under normal circumstances, FAST allocates documents a contentclass of STS_ListItem_DocumentLibrary and when search results are returned to the Core Results Web Part as an xml document, our document is accompanied by an imageurl element which points to an icon within the layouts folder (i.e.  /_layouts/images/icdocx.png).

When using a custom document library, let’s say with a type of 15000, the contentclass will be STS_ListItem_15000 and the Core Results Web Part will be returned an imageurl element of /_layouts/images/STS_ListItem16.gif.

This has been accepted as a bug by the product team. Unfortunately, So far as I know, it is not likely to be resolved in either upcoming hotfixes or Service Pack 1 (I have no visibility of any future CUs or Service Packs). The Microsoft-recommended workaround is to create a Custom Pipeline Extension whereby library items that have a contentclass of STS_ListIem_<a number> are converted to STS_ListItem_DocumentLibrary.

I’m checking into whether I can post some PSS-provided sample code for the pipeline extension, but until then, visit this page on MSDN to get instructions on how to create one.

Update 21 Sept 2012:  Baastian Kortenbout has provided code which addresses the issue. This can be downloaded here: FS4SP2010PipeLineExtensionIconFixer. I make no guarantees about the code, you assume all risks and responsibility should you chose to use it in any way, blah blah blah.

 

4 comments on “Missing document icons from search results with FAST for SharePoint

  1. Wouldn’t it be easier to modify the xslt and render the icon based on either the file extension or the mime type, instead of changing the contentclass?

  2. Thanks for the question Mikael,

    We did discuss that approach with our PSS engineer but the solution wasn’t scalable for several reasons which I’ll list below

    • Our client’s farm is effectively multi-tenant, meaning we have different FAST search centers, one for each internal customer. This would require manual updates to the search results for each new search ui
    • The xml passed back to the web part has the specific file name for each icon included. We would need to name explicit icon files whose name *could* change in the future. Unlikely, but possible. Same goes for a FAST CU adding indexing capability over new file types (you’d need to update the xslt)
    • The xslt for Local Sites Search is not customisable (this goes to a page called something like /_layouts/OSSSearchResults.aspx)

    It would be possible to workaround in specific circumstances, but we felt the long-term approach for the platform justified the Custom Pipeline extension.

  3. Hi Neil. Thanks for blogging about this bug. I wrote a Custom Pipeline Extension (C#) to change the contentclass of items that exist inside a custom document library. After hooking my fix in the FAST pipeline, document icons are displayed perfectly. Send me an e-mail or contact me through Twitter (@baskb) and I will send you the solution. Maybe you can add it to your blogpost?

  4. Hi Bastian

    I have noticed the same issue on our site.

    You offered Neil to send him your custom stage solution. Would you send it to me also?

    Thanks and best regards
    Marc

Leave a Reply

Your email address will not be published. Required fields are marked *