WordPress.org

Make WordPress Core

Opened 6 months ago

Last modified 6 months ago

#25693 new defect (bug)

blog_charset should be checked for null values

Reported by: ZaMoose Owned by:
Milestone: Awaiting Review Priority: normal
Severity: major Version: 3.8
Component: Charset Keywords:
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 (6)

comment:1 johnbillion6 months 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 fall back to UTF-8 we could still munge people's data.

Last edited 6 months ago by johnbillion (previous) (diff)

comment:2 follow-up: ZaMoose6 months 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 6 months ago by ZaMoose (previous) (diff)

comment:3 ZaMoose6 months 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.

comment:4 in reply to: ↑ 2 ; follow-up: johnbillion6 months 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.

comment:5 in reply to: ↑ 4 ZaMoose6 months 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 6 months ago by ZaMoose (previous) (diff)

comment:6 rachelbaker6 months ago

  • Cc rachel@… added
Note: See TracTickets for help on using tickets.