[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