[wp-trac] [WordPress Trac] #20773: update_option can't store serialized binary in wp_options.option_value column
WordPress Trac
wp-trac at lists.automattic.com
Tue May 29 11:44:21 UTC 2012
#20773: update_option can't store serialized binary in wp_options.option_value
column
--------------------------+-----------------------------
Reporter: mmaunder | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: General | Version: 3.3.2
Severity: normal | Keywords:
--------------------------+-----------------------------
If a plugin developer tries to use update_option to store an array
containing binary data, the array is not deserialized correctly and
update_option instead returns the start of the serialized string.
Test script you can use in a plugin:
{{{
$test = get_option('mdm', false);
error_log(var_export($test, true));
$binOn = true;
update_option('mdm', array(md5('asdf', $binOn), md5('qwer', $binOn),
md5('sss', $binOn)));
}}}
If we:
alter table wp_options modify option_value longblob;
Then it works correctly.
Because wp_options currently stores serialized PHP data as longtext
instead of longblob, the database receives the full binary data but
truncates it when trying to store it as utf8 characters. Making the column
binary appears to fix the issue because the database gives PHP back
exactly what was inserted.
The obvious answer is: create your own tables if you want to store binary.
But I'm reporting this because I worry that it may have more subtle
effects like incorrectly storing I18N chars when serialized.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/20773>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list