3

I am developing a Joomla! authentication plugin and have a standard Joomla! install (J3.9.1) with PHP 7.2 and MySQL 5.6.29. My plugin has config parameters that are accessible via the backend. One of these params is a notification text that must be displayed. If I use a German umlaut character in the notification text, for example the word 'über' (without the quotes), this word is initially stored and displayed correctly, but when the plugin is configured and saved once more, the umlaut character converts into gibberish. In the Joomla db #__extensions (collation utf8mb4_unicode_ci) the word is initialy stored in unicode as \u00fcber but is later stripped down to u00fcber.
In the standard Joomla authentication plugin Authentication-GMail, I can enter the same word 'über' in the 'User Blacklist' config param field and it will stay there forever, i.e. it is stored (in table #__extensions) as \u00fcber but the backslash is never stripped away.
So why the difference in behaviour between my plugin and Authentication-GMail and what can I do to be able to properly store foreign characters in my plugin notification text config param field?

  • Additional info: the form text field type in the related plugin config xml is 'textarea'. Changing it into 'text' doesn't help. – RobNL Jan 15 at 10:29
  • Update / Resolved: the problem appeared to be that my plugin is using its own code to retrieve the value of a config parameter, that is instead of the standard $this->params->get(). The reason is that the param is retrieved by a different plugin than the one that stores the param. The code was using - more or less basic - string processing which caused the problem. I am now using JSON to retrieve tha param value and now it is fine, in other words: problem solved! – RobNL Mar 22 at 11:26
2

The issue has been resolved. I have added the following comment to my question.

Update / Resolved: the problem appeared to be that my plugin is using its own code to retrieve the value of a config parameter, that is instead of the standard $this->params->get(). The reason is that the param is retrieved by a different plugin than the one that stores the param. The code was using - more or less basic - string processing which caused the problem. I am now using JSON to retrieve the param value and now it is fine, in other words: problem solved!

  • I copy pasted the explanation directly here and gave a +1 since this is an interesting thing people easily forget to check. – Ville Niemi Mar 22 at 13:00
0

First, try to set and use the textarea field with adding a filter attribute for that field like filter="raw" . This can help to solve the initial problem and the input text might be stayed as it is without stripping down that back slash during saving. It might be an instant solution.

Secondly, since we are talking about plugin parameters and this particular is a notification text thus you have to try a bit with character encoding before you show the called parameter in your layout (I am not convinced at all that yours is a character encoding problem, but you will check and see). I also had some headache about this when I worked with my own language strings.

Thus the approach I would use is when I get back and use the param then I use convert on the strings:

So to get the param in your view you use something like this:

$mystring = $this->params->get('mynotificationparamtext');

Then you can try with different conversions and you will see which one works for you, if it's an encoding problem.

  1. You can try with:

    $mydecodedparamtext = utf8_decode($mystring);
    // echo $mydecodedparamtext; // -- debug - to see what is the decode result
    
  2. you can try the opposite:

    $myencodedparamtext = utf8_encode($mystring);
    // echo $myencodedparamtext; // -- debug - to see what is the encode result
    
  3. you can try with PHP mb_convert_encoding, with that you can convert any encoding type to any other:

    $myencodedparamtext = mb_convert_encoding($mystring, "UTF-8", "ISO-8859-15");
    // echo $myencodedparamtext; // -- debug - to see what the convert result is
    

And so on...

Then you will see what encoding is giving you the correct string format with correct display.

I just hope that one of the above can solve the issue for you.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.