Content Search Web Part Doesn’t Open Documents in Office Web Apps

I recently came upon a situation where I had designed a beautiful new intranet page for one of our support functions. You know – typical stuff…a nice clean display presenting documents on a page instead of directly in a document library. Everything was going great until testing when I found that the SharePoint 2013  Content Search Web Part doesn’t open documents in Office web apps even if the library (or even site collection) is set to use the browser by default!

downloading
Oh, how I hate seeing this download bar!

Quick background – I had originally chosen to use a Content Query Web Part, but the same problem happens there – opening a file will open in the client app instead of the browser. This is unacceptable for the purpose of this small site. Users need to get in quickly, find the information they need, and get back to work (Get in. Get out. Get on with your life – R.I.P Windows Phone). We’re a global company and our SharePoint 2013 Farm is housed somewhere in Germany…this leads to sometimes frustrating experiences when opening content because of slow downloads. Opening Office documents and PDFs via Office Web Apps, though, often proves to be much faster and a better experience for my users.

I read several great posts on the matter, but they were all developer-focused. I mean, c’mon, who really wants to dig into XSL and XLST?! Not this non-developer…I’ll tell you that for sure. However, my understanding of SharePoint Search and managed properties came in handy here. If you’re familiar with the Content Search Web Part you know that there is an option to customize the property mappings used in the display template

JOY!

This is where your life becomes easier and now you don’t have to change any code. The ServerRedirectedURL managed property comes to the rescue – this property honors the WOPI bindings and behavior that you’ve defined for your library. Change the Link URL property to ServerRedirectedURL in the Content Search Web Part settings and the display template will now use the proper URL in the item hyperlink

Content Search Web Part
Content Search Web Part Property Mappings

 Caveats

Unfortunately, there are some caveats to be aware of.

  • Link to Document content type – if your library makes use of this…meaning you have an item in the search results that is a redirect to another document the ServerRedirectedURL managed property is null.
  • Non-standard file types – I haven’t tested this with image files or CAD (e.g. DWG)
  • The URL won’t be pretty. As you probably know you can just tack on “?web=1” to the end of a document file URL to have it open in the browser. You’ll get the full, ugly URL going this route. Totally worth it to me in the specific case.dirtyURL

Hopefully, this saves some folks time and frustration. My understanding is that this problem has been around since SharePoint 2010 and exists still in SharePoint Online.

Add a Comment

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