Catalog Search Sorting Broken With Umlauts / Special Characters

Question

There is a catalog search Magento bug in 1.9.3.0 - 1.9.3.4. You can reproduce it like that:

1. Create a product with an umlaut in the name like "über".
2. Search for the umlaut like "ü" in the frontend.
3. Search results are shown. Now change the sorting from "relevance" (default) to e.g. "name".
4. Encounter the bug:
   1. [expected] see the results ordered by name.
   2. [actual] see a broken page:

Mind that this is NOT an .htaccess issue as described here. How can this be solved?

Answer 1

Thanks Simon for the correct analysis of the bug. Magento Core changed but the theme didn't.

Your proposed solution works but i don’t like getting an encoded value from the block, decoding it with rawurldecode and encoding it again in function setLocation.

So my solution is as follows:

Just change the onChange-handler of the order select element in app/design/frontend/rwd/default/template/catalog/product/list/toolbar.phtml from

<select onchange="setLocation(this.value)">

to

<select onchange="window.location.href=this.value">

As setLocation only performs a call to encodeURI we can safely remove the call to setLocation and set the window url directly as we know the url is encoded. Function setLocation for reference:

function setLocation(url){
    window.location.href = encodeURI(url);
}

Answer 2

The issue was awfully hard to debug, but in the end, the solution is easy.

The links for the sorting are inserted in an escaped manner into the page. Example:

<option value="http://shop.local/catalogsearch/result/index/?dir=asc&amp;order=name&amp;q=%C3%BC">Name</option>

When the select element is changed, the function setLocation(this.value) from js/varien/js.js is called. It basically simply does a

`window.location.href = url;`

Unfortunately, since Magento 1.9.3.0, the implementation has been extended with an encodeURI:

`window.location.href = encodeURI(url);`

This means that these links are encoded twice. Once when inserted into the page (mind the %C3%BC in the option value above) and once when switching the location. Then, the param %25C3%25BC (% is encoded with %25) is sent to the server, so that the request fails.

My solution was to override the template app/design/frontend/rwd/default/template/catalog/product/list/toolbar.phtml and change the following call:

$this->getOrderUrl($_key, 'asc')

to:

rawurldecode($this->getOrderUrl($_key, 'asc'))

Mind that you also need to wrap the getLimitUrl call!

Not sure if this is the most elegant or most secure solution, but it works at least ;-)