There are two single line text boxes (short and long). Which one are you referring to? The long one should use exactly the same view as the standard profile plugin.

It appears to be on both of the single line text boxes (250px wide and 100% width).

The multiline text box is fine though.

I have checked the code and the 100% width text box uses the same view as the standard profile system (input/text).

So in that case I cannot see how this problem can be occuring. As I cannot test this myself, I'm afraid that you are on your own. If you can figure out a fix, please post it here.

I do notice that the 250px text field type uses:

value="<?php echo htmlentities($vars['value'], null, 'UTF-8'); ?>"

whereas the new input/text field (used by the 100% width field type and the default profile type) now uses:

value="<?php echo htmlentities($vars['value'], ENT_QUOTES, 'UTF-8'); ?>"

 I will make that change for the next release.

That would not affect the 100% width text field type however.

I should have said that "I cannot reproduce this myself" rather than "I cannot test this myself".

I have tested it and everything works as expected.

ok thanks Kevin. I will try it in a fresh install and go from there - maybe it's clashing with another mod.

Kevin , could you test one thing for me - if you enter the character á (Alt Gr + a), when you look at the metastrings table does it save as á or does it save as Ã?

I just tried this out on my Elgg install and it is saved as á in the metastrings table.

I do notice that the latest profile code does this to values:

if (is_array($value)) {
                array_walk_recursive($value, 'profile_array_decoder');
            } else {
                $value = html_entity_decode($value, ENT_COMPAT, 'UTF-8');
            }

before saving them, which my flexprofile code does not do.

You could add that code after line 278 of mod/form/models/profile.php to see if it makes a difference for you.

Interesting - it is saving as à in mine.

If I create a new blog post, the data in the title field also gets saved as à in the metastrings table but this is displaying correctly on screen so there must be some data conversion going on which is not happening for the profile page.