Tuesday, September 9, 2014

SharePoint 2013: VIEW PROFILE link on Search Popup displays Incorrect URL Encoding

Problem

When your users click on the VIEW PROFILE link, displayed on the popup when hovering the cursor over a search result, clicking the link navigates the user to a Sorry, something went wrong page.  When you inspect the URL for this hyperlink, you notice that it seems to include extra encoding:
...Person.aspx?accountname=DOMAIN%255CStephan%252EBren
You check other user profile hyperlinks at the site (eg, Modified By, etc), and these seem to use the standard encoding:
...Person.aspx?accountname=DOMAIN%5CStephan%2EBren

...Person.aspx?accountname=i%3A0%23%2Ew%7CDOMAIN%5Cstephan%2Ebren (claims-based)
Solution
  1. Perform the following steps on each web front end (WFE) server:
    1. Login under an account that is a member of the local Administrators group (I regularly use the SharePoint Setup User Administrator account).
    2. Using Windows Explorer, open up this location:
      C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\LAYOUTS
    3. Scroll down until you find these two files:
      • Search.ClientControls.debug.js
      • Search.ClientControls.js
    4. Copy these two files to another location as backup copies.
    5. Now, for each file, remove the function encodeURI( ...), but leave its argument.  This is the function causing the problems.  You want to leave its argument since it creates the appropriate URL.  To find them, just search for this function name.  Thus,
      encodeURI(Srch.U.ensureAllowedProtocol(STSHtmlDecode(str.value)));
      becomes
      Srch.U.ensureAllowedProtocol(STSHtmlDecode(str.value))
      There will be two such instances of this in each file. Do them both.
    6. Save the file.
    7. To detect the change in your browser, you may need to do CTRL+F5 to refresh the cache.  No IIS reset necessary: this is only a change in JavaScript library.
References
Notes
  • Thanks to Trevor Seward for identifying and resolving this.
  • I first tested in development farm, and then performed in production.  No issues experienced.  Simple to implement.
  • UPDATE 9/12/14: Trevor Seward reports that this has been resolved in the September 2014 CU.  Have not yet installed this so looking forward to verifying.

No comments: