WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 9 months ago

#25693 new defect (bug)

blog_charset should be checked for null values

Reported by: ZaMoose Owned by:
Milestone: Future Release Priority: normal
Severity: major Version: 3.8
Component: Charset Keywords: needs-patch
Focuses: Cc:

Description

We've encountered an error wherein a blog in a multisite network's blog_charset was nuked. This led to posts entered from the editor (visual and text) having random bits eaten. This was particularly pronounced when using text copied from Word documents. This is related to #23688, I think.

It seems as though PHP 5.4 makes some weird assumptions when you have a blank/null charset. Suggest we check for null values and fall back to, say, UTF-8 if none is found.

@grantlandram, @dkotter and I found this one under duress.

Change History (9)

#1 @johnbillion
3 years ago

How did the value get nuked? Human error?

It might be better to kill the admin area with a wp_die() message if blog_charset isn't set or is empty. If we try to fallback to UTF-8 we could still munge people's data.

Version 0, edited 3 years ago by johnbillion (next)

#2 follow-up: @ZaMoose
3 years ago

@johnbillion:
It was somehow cleared when clicking the "Update siteurl and home as well." under the site settings in the Network. I'm at a loss to explain as to how that was the cause, but the vast majority of the site's settings were cleared after that.

In any event, the blog_charset was cleared along with those other settings and lead to the anomalous posting behavior we saw. We only detected this by connecting w/Sequel Pro and looking at the individual options tables. (Could've just gone to options.php per instance, too.)

wp_die()ing might not be the most user-friendly way to approach it, but I definitely think we do need to alert the users somehow.

Last edited 3 years ago by ZaMoose (previous) (diff)

#3 @ZaMoose
3 years ago

Additional info:
We discovered this on a site still running WP 3.5, but have confirmed it as an active bug on everything up to and including trunk.

#4 in reply to: ↑ 2 ; follow-up: @johnbillion
3 years ago

Replying to ZaMoose:

wp_die()ing might not be the most user-friendly way to approach it, but I definitely think we do need to alert the users somehow.

Yeah but I think we need to block interaction at this point to prevent the data loss (or data corruption) that you experienced. Clearly an edge case, but not a nice one.

#5 in reply to: ↑ 4 @ZaMoose
3 years ago

Replying to johnbillion:

Yeah but I think we need to block interaction at this point to prevent the data loss (or data corruption) that you experienced. Clearly an edge case, but not a nice one.

One weird thing to note: in certain scenarios, we were noticing that autosaves were capturing the content, while user-initiated explicit save ops were eating it. I haven't looked too closely into this, but that at least suggests to me that we may want to see how the AJAX stuff is interacting differently and attempt to catch this there, too. (That is, if we feel like it could lead to data loss somehow.)

Since we've hidden the charset setting from the admin, what would be the best way to allow for this? I doubt we want to start suggesting that users edit the wp_options table directly.

Last edited 3 years ago by ZaMoose (previous) (diff)

#6 @rachelbaker
3 years ago

  • Cc rachel@… added

#7 @wonderboymusic
2 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

#8 @sanchothefat
9 months ago

@ZaMoose hello! Do you remember which release of PHP 5.4 you had running when you ran into this? Also the charset for the main site and others if you have that info.

Possibly related bugs from the PHP changelog:

#9 @ZaMoose
9 months ago

@sanchothefat:
Alas, no I don't. I believe it was one of the PHP 5.4 versions that the 3rd party Remi repository hosts for CentOS/RedHat Enterprise hosts.

Note: See TracTickets for help on using tickets.