FIX: Fix to allow use of foreign text as tags and categories. Fixes …

[gordonbanderson]

Instead of using the URL parameter directly for a tag or category value, generate a URL segment initially and search using that. This fixes the issue of likes of Thai text not being found.

[assertchris]

Thanks for this. Just want to test it out locally, but it looks good...

[assertchris]

I've tested this and it works. If you wouldn't mind rebasing it, I'll merge it! :)

[tractorcow]

Hi @gordonbanderson I have had a look at the sourced issue and your fix, and I'm not sure that passing the argument through the URLSegmentFilter twice is going to be ideal. we run the risk of "double encoding" in edge cases.

The root issue is that any extended characters are automatically decoded by the time it gets to this method. All that's necessary is to ensure that we cope with any decoded value by re-encoding it as it's stored in the database.

This is the fix I've added to include the encoded value as a fallback.

        if($tag) {
            return $dataRecord->Tags()
                ->filter('URLSegment', array($tag, rawurlencode($tag)))
                ->first();
        }

My main concern is that we are running the queried string past all the other logic which really has nothing to do with url decoding (such as checking for duplicate tags, plus other transformations on the string).

[tractorcow]

@gordonbanderson can you please see if #263 fixes your issues?

[gordonbanderson]

Looks like I was too late to test :) I did feel regenerating the URLSegment was a bit icky but I needed a quick fix, your solution appears cleaner. Will test tomorrow.

[gordonbanderson]

can confirm above fix works