WordPress.org

Making WordPress.org

Opened 3 years ago

Closed 2 years ago

Last modified 10 days ago

#3284 closed defect (fixed)

Character bug on profile name

Reported by: anonymized_18317310 Owned by:
Milestone: Priority: low
Component: Profiles Keywords: needs-patch
Cc:

Description

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

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

Attachments (1)

meta-3284_fixed-example.png (128.0 KB) - added by coffee2code 2 years ago.
Example of profile name with different charsets, after fix

Download all attachments as: .zip

Change History (32)

This ticket was mentioned in Slack in #meta by jranavas. View the logs.


3 years ago

#2 @SergeyBiryukov
3 years ago

  • Component changed from General to Profiles

#3 @anonymized_18317310
3 years ago

  • Resolution set to worksforme
  • Status changed from new to closed
Last edited 10 days ago by anonymized_18317310 (previous) (diff)

#4 @anonymized_18317310
3 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened
Last edited 10 days ago by anonymized_18317310 (previous) (diff)

#5 follow-up: @obenland
3 years ago

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

#6 follow-up: @Otto42
3 years ago

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.

#7 @anonymized_18317310
3 years ago

Last edited 10 days ago by anonymized_18317310 (previous) (diff)

#8 in reply to: ↑ 6 @obenland
3 years ago

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?

#9 @anonymized_18317310
3 years ago

Last edited 10 days ago by anonymized_18317310 (previous) (diff)

#10 @dd32
3 years ago

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.

#11 @ocean90
3 years ago

#3249 was marked as a duplicate.

This ticket was mentioned in Slack in #meta by obenland. View the logs.


2 years ago

#13 @ocean90
2 years ago

#3696 was marked as a duplicate.

#14 @kalich5
2 years ago

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!

This ticket was mentioned in Slack in #meta by pento. View the logs.


2 years ago

#17 @sebastienserre
2 years ago

  • Keywords needs-patch added

This ticket was mentioned in Slack in #core by desrosj. View the logs.


2 years ago

This ticket was mentioned in Slack in #core by sebastienserre. View the logs.


2 years ago

This ticket was mentioned in Slack in #meta by buxert. View the logs.


2 years ago

#21 in reply to: ↑ 5 @SergeyBiryukov
2 years ago

Replying to obenland:

Has this never been a problem before?

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

@coffee2code
2 years ago

Example of profile name with different charsets, after fix

#22 @coffee2code
2 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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).

#23 @coffee2code
2 years ago

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.

#25 @coffee2code
2 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

#26 @coffee2code
2 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

#27 @kalich5
2 years ago

it works. :-)

#29 @sebastienserre
2 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Hello,
Not completely fixed :
https://i.imgur.com/7s8zA2n.jpg
Profile URL: https://profiles.wordpress.org/sebastienserre/

#30 @kalich5
2 years ago

Yes, this is not fixed yet.

https://i.imgur.com/sWicaDl.png

#31 @coffee2code
2 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.
Note: See TracTickets for help on using tickets.