Make WordPress Core

Opened 16 years ago

Closed 15 years ago

Last modified 14 years ago

#6784 closed defect (bug) (fixed)

options with content in strange languages do not deserialize properly

Reported by: olav-kolbu's profile Olav Kolbu Owned by:
Milestone: 2.8 Priority: normal
Severity: normal Version: 2.5
Component: General Keywords: deserialize, get_option, character sets
Focuses: Cc:


Put this in a php-page that has access to the get_option()/update_option() fns and load page TWICE.

$test = get_option('my_test');
if ( is_bool($test) ) {

print "1st time<br>";
$test = array();
$test[] = 'ي';
update_option('my_test', $test);
print 'Arabic : '.gettype(get_option('my_test')).'<br>';

} else {

print "2nd time<br>";
print "got a ".gettype($test)." which looks like '$test'";


Note that the content of the string on line 5 is an arabic character. If you're having troubles regenerating it, print & # 1610 ; (without spaces...) on a webpage and cut'n'paste it from there. I have also attached it to this bug report, I hope.

First time the page loads, the output is:

1st time
Arabic : array

Which is what you would expect. Note specifically that the array tested is the one that is stored and then fetched again, not the original array.

Now reload page and you get:

2nd time
got a string which looks like 'a:1:{i:0;s:2:"?";}'

So the backend didn't deserialize the array this time around. Now, I can work around this feature/bug in my own plugin-code by never storing strings with strange characters, but this also bites me when I use the MagpieRSS caching features, as the feed stored may contain strange characters and I can't control the content of those.

Attachments (1)

bug.php (314 bytes) - added by Olav Kolbu 16 years ago.
Short php file to reproduce the bug

Download all attachments as: .zip

Change History (8)

@Olav Kolbu
16 years ago

Short php file to reproduce the bug

#1 @ryan
16 years ago

Your example works for me. Are DB_CHARSET or DB_COLLATE defined in your wp-config.php file? If so, what are their values? What is the collation on your options table? You can check this in phpmyadmin or use the SQL statement "SHOW TABLE STATUS" and look at the Collation column.

#3 @Olav Kolbu
16 years ago

Your suspicions were right. My collation on wp_options is latin1_swedish_ci. DB_CHARSET is 'utf8', DB_COLLATE is ''.
Read up on charsets in WP and presumably I'm a victim of the pre-2.2 defaults. I've converted
my tables to utf8_general_ci now (using a plugin), and my test no longer fails. My Google News plugin now appears to handle cyrillic, arabic and other languages fine as well. Thank you for your time and feel free to close this bug as solved. You might want to add an admin-warning somewhere if the mysql table types do not match the selected charset for the blog though? Perhaps in the upgrade-script.

Oh yeah, if you're bored there should be a system for clearing out old cached MagpieRSS feeds. As it is now they're just accumulating in wp_options, and at several hundred kb a pop that can quickly grow a database. Would have supplied the code for this, but I suspect you're planning on ditching MagpieRSS anyway. :-)

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

#4 @ryan
16 years ago

  • Milestone changed from 2.5.2 to 2.9

Milestone 2.5.2 deleted

#6 @Denis-de-Bernardy
15 years ago

  • Milestone changed from 2.9 to 2.8
  • Resolution set to fixed
  • Status changed from new to closed

should be fixed, now.

Note: See TracTickets for help on using tickets.