Service Provider schedule gets reset when manually confirming appointments

I currently allow Service Providers to manually set their own hours and confirm their own appointments on their profile page within Buddypress. When they confirm an appointment, their hours are reset to “No” for every day, along with the 12:00am – 12:30am working hours. This also occurs when an appointment is already confirmed, but they check the ‘confirm’ box and click save anyway.

Looking at the code, I see this:

$result = $wpdb->update( $this->wh_table,
array( 'hours'=>serialize($_POST[$stat]), 'status'=>$stat ),
array( 'location'=>$location, 'worker'=>$profileuser_id, 'status'=>$stat ),
array( '%s', '%s' ),
array( '%d', '%d', '%s' )

When I look at my DB values, the hours column before the hours-reset bug contains the serialized value, thusly:

a:7:{s:6:"Sunday";a:3:{s:6:"active";s:3:"yes";s:5:"start";s:8:"12:00 am";s:3:"end";s:8:"12:00 am";}s:6:"Monday";a:3:{s:6:"active";s:3:"yes";s:5:"start";s:8:"12:00 am";s:3:"end";s:8:"12:00 am";}s:7:"Tuesday";a:3:{s:6:"active";s:3:"yes";s:5:"start";s:8:"12:00 am";s:3:"end";s:8:"12:00 am";}s:9:"Wednesday";a:3:{s:6:"active";s:3:"yes";s:5:"start";s:8:"12:00 am";s:3:"end";s:8:"12:00 am";}s:8:"Thursday";a:3:{s:6:"active";s:3:"yes";s:5:"start";s:8:"12:00 am";s:3:"end";s:8:"12:00 am";}s:6:"Friday";a:3:{s:6:"active";s:3:"yes";s:5:"start";s:8:"12:00 am";s:3:"end";s:8:"12:00 am";}s:8:"Saturday";a:3:{s:6:"active";s:3:"yes";s:5:"start";s:8:"12:00 am";s:3:"end";s:8:"12:00 am";}}

along with a corresponding row for the ‘closed’ hours (these were for ‘open’ hours).

After the hours-reset bug, I get a simple N; for both ‘open’ and ‘closed’ hours.

I also notice in the PHP manual for serialization that “this is a binary string which may include null bytes, and needs to be stored and handled as such. For example, serialize() output should generally be stored in a BLOB field in a database, rather than a CHAR or TEXT field.” The hours column stores values in the hours column as text…is this possibly causing an issue?

I’ve replicated this bug on a fresh, untainted version of the appointments.php file, so it’s nothing I’ve done to the file, as far as I can tell. Can anyone else replicate this?