Special Characters

I've the same problem.

Seems like there is no solution given the time this issue was created and no responses to it.

Did you find a work around for this Keith?

Hmm, interesting. Obviously I have too many check_plains in place. Can you look at the "realname" table in the database and see how it appears there, please.

Hey Nancy,
Thanks for the reply. Yes on the DB it shows the user name with "&" instead of "&".

mysql> select * from realname where uid = 117;
+-----+-------------------------+
| uid | realname |
+-----+-------------------------+
| 117 | Town & Gown Players |
+-----+-------------------------+
1 row in set (0.00 sec)

Hope it gives you light :)

In line 809 (the end of function _realname_make_name), you will find

  return filter_xss_admin($string);

It is there for security, but seems to be a bit aggressive in that department. Change it to

  return html_entity_decode(filter_xss_admin($string));

Humm... in which file? :P

PERFECT Nancy!

Thank you very much. That was spot on! ;)

I guess you found it.

Hmmm ... what about apostrophes?

Tried changing realname for Website Admin to Web'site Admin

+-----+-------------------------+
| uid | realname |
+-----+-------------------------+
| 1 | Web & #039 ;site Admin |
+-----+-------------------------+

Unfortunately, I've now got a "D'Silza", which is causing havoc on my production site. :(

Modifying line 809 works for display, but I can't match the user in a realname_user_reference widget.

EDIT: I should clarify ... realname autocomplete works, as long as you don't actually type the special character ... once you get past the apostrophe, you get no matches.

EDIT 2: Nevermind ... apparently it does work on my node creation form ... but doesn't work on another page where the autocomplete is coming back with the & #039 ; notation even though the database is now correct. Looks like it may be an issue with my implementation.

Actually when I was correcting that code, I did use an O'Neill, so the apostrophe was tested.

The autocomplete can be up to either the Forms API or the supplying module, either of which may be doing a check_plain that encodes the entity. RealName has no control over either of them, and, for security reasons, probably should not.

Committed to 6.x-1.x-dev.

So, just to make sure I'm understanding -- you are saying to use that code snippet and the apostrophe problem is fixed? Ended up here today as I have an apostrophe in O'Rourke that is displaying as ascii code. Or, are you saying RealName has no control over this and it's a problem at the api or profile module, in my case, level? Sorry to be dense. Bad day.

The code in the latest -dev version includes this fix. However, what I was saying is that an autocomplete list is a horse of a different color and RN may not be able to do anything about the list because it is created elsewhere.

This problem is back in version 7. I didn't know if I should create a new issue or just update this one with the version set to 7... (which I did - please correct me if I'm wrong).

Apostrophes display as & # 0 3 9 ; in Realname. They are saved that way in the database.

I ran into this problem as well. RealName uses token_replace, based on the settings you provide in the configuration. By default, it uses the raw username, however if you have custom fields in the user profile and set the token replacement pattern to say: [user:first_name] [user:last_name], then it seems to be that the input is filtered after the token replacement.

This patch reverts any HTML special character encodings.

No, the tokens for fields shouldn't be filtering anything since we request the tokens with 'sanitize' => FALSE.

Let's not re-open an issue that's been closed for two years. Please file a new issue.