In our Intranet we got this nasty double encoding error that was introduced in SharePoint April 2014 CU. In July 2014 CU the problem is still there. I often hear the suggestions to update files directly in the hive (the root folder for SharePoint: C:Program FilesCommon Filesmicrosoft sharedWeb Server Extensions15) In that blog post it is described what the problem is and what files are affected and what code must be altered in order to get it to work (which I like). But it is also suggested to update the Search.ClientControls.js directly on the server (which I don’t like). So my advise is:

Do not mess with the SharePoint hive

Even though you have access, treat it as a black box, because

• you don’t want to update the full file and the minified version of it on all servers and keep track of possible changes
• you don’t want to loose Microsoft support because you have messed up the application folder
• you want to think Cloud and Cloud-Ready. In Office 365 you’ll never get access to the hive.

What to do then?

Allright, enough said about the theory. What should we do to solve this issue? Here is my suggestion

1. Find out how critical it is, perhaps you can wait until the next CU is released
2. Contact Microsoft and let them fix it
3. Find an alternative solution.

A solution without messing with the hive

To solve this particular problem, we can inject our fix into the Search.ClientControls.js on the fly using the SP.SOD framework. The problematic function is the $urlHtmlEncode. Before the April 2014 CU it looked as follows:

So now we can reset it back through our code. Just add these lines of code to a javascript file that is loaded on all pages (within a custom master page, or a custom user action):

This code will register code for resetting the problematic function and execute when Search.ClientControls.js is loaded. On pages where Search.ClientControls.js is not loaded (on the majority of the pages except the Search Center), this function will not execute.