Character bug on profile name

[anonymized_18317310]

I realized one bug when you select a latin character (at least with "ó"):

• On WordPress.org, "�" character shows instead on the right top profile menu.
• The profile name dissapeared (at least for me)

In the second point, is not a browser bug, the code don't show the name.

[anonymized_18317310]

Appears solved with the new WP.org theme update!

Also, ticket #3249 can be closed.

Thanks.

[anonymized_18317310]

Now just reappeared

[obenland]

@otto42 Has this never been a problem before? Where would I start debugging this, I'm unfortunately zero familiar with Profiles.

[Otto42]

His name is showing up on the profile for me right now, so doesn't appear to be an issue.

However, this is likely a symptom of a deeper problem with regard to our database tables. That's a whole other bucket of worms. Dion knows more about the problem than I do, but the short of it is that all the tables are using latin1 instead of utf8, and we're storing utf8 data in them, and the hyperDB database later has various issues with converting, and so on.

It's not an easy problem and I just tend to spot fix when I find them. ATM, this seems to be a fixed problem specifically on profiles.

[anonymized_18317310]

Thanks for looking at this.
Maybe when I updated the profile from WP admin profile was fixed.
For now It's solved but tell me if I can test anything.

[obenland]

Replying to Otto42:

His name is showing up on the profile for me right now, so doesn't appear to be an issue.

For me too, which makes it all the more interesting. I changed my name to Kónståntîn Obénland, and ​it's not showing. :)

@dd32 Any idea about how to best fix this?

[anonymized_18317310]

Hmmmm interesting @obenland, try to change it on ​https://wordpress.org/wp-admin/profile.php
That solved my name, maybe it is stored different than in profiles?

[dd32]

This is something to do with the fact that buddypress.org/profiles.wordpress.org is forced into utf8 mode where as every other site on w.org (and the shared database being used for it all) is latin1.
I don't know why BuddyPress is using utf8, I think the idea was to solve this kind of problem, but it only causes more of them IMHO.

I'm not sure of the best way forward myself, as I'm not sure where the issue is.

Probably need to track down where the data is being inserted or retrieved incorrectly, or maybe even a cache being retrieved and fix the DB collation for the query - There's a few places where we do something akin to $current_collation = $wpdb->.....; $wpdb set as utf8; $wpdb->get_results(); $wpdb set as $current_collation to temporarily switch types.

I know there's another ticket for a Profiles refresh, unfortunately I doubt that'll fix the DB issues and we'll probably end up building more of these issues in.

To debug, one option may be to temporarily disable memcache for your sandbox and see if when it's using just straight DB access if things break or not. Unfortunately disabling memcache will probably result in some really bad queries and super-slow page loads for certain things that might mean debugging is impossible.

[ocean90]

#3249 was marked as a duplicate.

[ocean90]

#3696 was marked as a duplicate.

[kalich5]

I have the same problem ​https://profiles.wordpress.org/skaut

The error has been reported for more than half a year. She would want to fix it at last!

[sebastienserre]

Hello,
Same problem here
​https://profiles.wordpress.org/sebastienserre

[SergeyBiryukov]

Replying to obenland:

Has this never been a problem before?

Previously: #226, #516, #682, #1208.

[coffee2code]

Example of profile name with different charsets, after fix

[coffee2code]

Fixed in [14405-dotorg] and [14406-dotorg].

Affected users will likely need to re-save their display name via either their profiles.wordpress.org profile (the "Name" field) or their support forum profile (the "Display Name" field).

[coffee2code]

As explained upticket, the primary user account data is stored in a database that is latin1. BuddyPress/Profiles runs in a database that is utf8. The differing charsets can cause issues during cross-database reads and writes. For this specific set of issues, the display_name user field can be set via a user's profiles.wordpress.org profile or the support forums profile. If set via profiles.wordpress.org, utf8 data was getting saved into the latin1 user table. If set via the support forums profile, the Profiles name could appear ok, but the "Logged in as:" name wouldn't be proper. The two commits fix the issues by ensuring latin1 is used for these particular reads/writes.

This doesn't fix the data that is already stored as the user's display_name. Such users would just need to edit their profile (in either location) and save the changes. In Profiles, it's the "Name" field, in the support forums profile it is "Display Name".

meta-3284_fixed-example.png​ shows a Profile with characters in the name that would have not rendered properly before the fixes.

[skaut]

It still does not work ​https://profiles.wordpress.org/skaut

[coffee2code]

Sorry, this issue is still not resolved. I was testing on my sandbox with user caching disabled, but with it enabled things aren't behaving properly. I'm investigating.

[coffee2code]

Ok, this should be fixed as of [14409-dotorg]. As before, those affected may have to re-save their display name (described above).

[kalich5]

it works. :-)

[sebastienserre]

Fixed for med
​https://profiles.wordpress.org/sebastienserre/

[sebastienserre]

Hello,
Not completely fixed :

Profile URL: ​https://profiles.wordpress.org/sebastienserre/

[kalich5]

Yes, this is not fixed yet.

[coffee2code]

The remaining issues outstanding since I last commented have been addressed:

• [14426-dotorg] from 2018-09-11 fixed the display of characters in page titles
• [14493-dotorg] and [14494-dotorg] from yesterday disabled reporting and display of profile-related actions, which appears to be the only activity type that exhibited poor character handling.