Problem with umlauts and tag element search list (still not working)

[JTe]

It looks like umlauts (characters like ä ö and in fact other utf characters too) do not work with the tag element search list.

If I have a tag element and when I start typing a word like "sähkö" I will get the following debugging output
(the word I typed is sent with url encoding the utf8 characters):

?option=com_fabrik&view=list&listid=14&format=tags&elID=151&like=s%C3%A4hk%C3%B6

In the above case the matching string for tag search seems to be "shk", so the url encoded characters are just dropped off.

However the response is coming without the url encoding (if I set the minimum length for a matching string to 1 and the match is against "s"):

option: com_fabrik
view: list
listid: 14
format: tags
elID: 151
like: sähkö

I guess the problem occurs when searching a tag and a url encoded string is used to match the tag. Would it be possible to "urldecode" this search string before trying to match it to the tag?

 

[troester]

What do you mean with "tag element search list"?
In list filter (type autocomplete) and in the tag element itself umlaute are working.

 

[JTe]

I mean this. So when I enter a tag in a input form with umlauts and I am typing it the typed text does not match to the tag already in the tags db:


If I however type a matching part of the word without umlauts I will get a match:


Now that the tags element has loaded the matching tags, I can type the word with umlauts and I have a match:


What I did debug is when the matching tags are fetched by the javascript, it is with this:

&format=tags&elID=151&like=s%C3%A4hk%C3%B6

(tags element, elelement id 151, and the search key s%C3%A4hk%C3%B6, which is urlencoded)

If I search the matching part without umlauts, like "veturi", I have:

&format=tags&elID=151&like=veturi

The problem is not the matching in the tag-element javascript part when the search list is already loaded. The problem is to get the correct search list from the tags db.

 

[JTe]

Ok, I find a solution. The problem was probably related to utf8 characters cut away in the file com_fabrik/views/list/view.tags.php on line 84:

if (stristr($d->text, $input->get('like')))

If I add the JInput "STRING" filter to that line:

if (stristr($d->text, $input->get('like','','STRING')))

Everything works fine!

I guess that should be also changed in git...

 

[JTe]

It seems that the above pull request is not included in the newest version of Fabrik (3.9.2), as after the update I have the problem again.

I guess the problem has something to do with the mysql collation in use. I think the reason is that JInput is defaulting to filter 'CMD', but to be absolutely safe with strings we should use filter 'STRING'.

Could somebody please fix this in the code.