options with content in strange languages do not deserialize properly

[Olav Kolbu]

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.

[Olav Kolbu]

Short php file to reproduce the bug

[ryan]

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.

[Viper007Bond]

See also: #6532

[Olav Kolbu]

Hi!
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. :-)

[ryan]

Milestone 2.5.2 deleted

[Denis-de-Bernardy]

invalid?

[Denis-de-Bernardy]

should be fixed, now.

[Denis-de-Bernardy]

See also #12302