urldecoded URL rewrites grid custom columns

[mwgamble]

We ran into an issue recently where we had a need to create URL keys for products and categories with non-Latin characters, and they were not showing up properly in the URL rewrites grid. The URL keys are stored in the database in their encoded form with all of those ugly percent signs, and only decoded when they need to be displayed. We utilised EAG custom columns to achieve this in the URL rewrites grid.

This adds custom columns for the URL rewrites grid that urldecode ID, request and target paths when viewing them. In order to allow filtering with these non-Latin characters, we also have to add a custom filter class which encodes the value entered by the user.

As you can see from the third commit, currently we have to set the value on the filter object, then get the condition array, then set it back to the decoded version again. It would be nice if we could just pass the encoded version to the getCondition() method to avoid having to do this. Could you advise on whether we missed something, or if we should be going about this differently?

[mage-eag]

Regarding the need to re-use setValue on the filter block with the encoded value, I would suggest to instead use your own filter class, that would itself take care of the URL encoding behind the scene (as you did for the renderer).

Also, you may want to remove the possibility for the user to choose the rendering of the column, because the only relevant and/or compatible choice seems to be "Text". Two ways of doing :

• force the text renderer (define a getLockedRenderer method in your custom column class, returning 'text'), to keep the corresponding configuration options. You will need to make your filter and renderer blocks extend from the corresponding original blocks, and apply the necessary changes (eg, regarding the wildcards handling).
• remove the allow_renderers part from the column definitions, so that only the base behaviour will be usable. This might be a good compromise, especially if the need for configuration is not high.

[mwgamble]

Hi, just wanted to let you know that I've finally got around to updating this pull request to use a custom filter block. I'd appreciate your thoughts on any potential improvements.

While I was working on this, I realised that slashes in URL paths were being encoded, meaning any searches involving slashes wouldn't return anything. The solution to this was to break up the path and encode each component of the URL path, as per this stackoverflow answer: http://stackoverflow.com/a/7973896/