WordPress.org

Making WordPress.org

Opened 2 years ago

Closed 14 months ago

#3284 closed defect (fixed)

Character bug on profile name

Reported by: jranavas 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 (2)

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

Download all attachments as: .zip

Change History (33)

@jranavas
2 years ago

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


2 years ago

#2 @SergeyBiryukov
2 years ago

  • Component changed from General to Profiles

#3 @jranavas
2 years ago

  • Resolution set to worksforme
  • Status changed from new to closed

Appears solved with the new WP.org theme update!

Also, ticket #3249 can be closed.

Thanks.

Last edited 2 years ago by SergeyBiryukov (previous) (diff)

#4 @jranavas
2 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Now just reappeared

#5 follow-up: @obenland
23 months 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
23 months 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 @jranavas
23 months ago

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.

#8 in reply to: ↑ 6 @obenland
23 months 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 @jranavas
23 months ago

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?

#10 @dd32
23 months 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
22 months ago

#3249 was marked as a duplicate.

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


18 months ago

#13 @ocean90
17 months ago

#3696 was marked as a duplicate.

#14 @kalich5
17 months 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.


17 months ago

#17 @sebastienserre
17 months ago

  • Keywords needs-patch added

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


16 months ago

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


16 months ago

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


16 months ago

#21 in reply to: ↑ 5 @SergeyBiryukov
16 months ago

Replying to obenland:

Has this never been a problem before?

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

@coffee2code
16 months ago

Example of profile name with different charsets, after fix

#22 @coffee2code
16 months 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
16 months 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
15 months 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
15 months 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
15 months ago

it works. :-)

#29 @sebastienserre
15 months 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
15 months ago

Yes, this is not fixed yet.

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

#31 @coffee2code
14 months 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.