Create a repeating hour block. Switch to a later instance and update the hours. Choose to update all future instances and nothing will appear to happen. Console logs reveal 500 HTTP header.
The cause is that several DB API calls are failing. It seems there are old Drupal 6 style API calls. Most notably in: opening_hours_repeat_stop_propagation().
There is another bug occurring that stops this functionality working but I've not tracked down the route cause. 'repeat_end_date' of an $instance is failing to be unset when not intended to be set before a drupal_write_record call. Which then causes a PDO exception because it tries to set a date column to a string value of 'null'. I believe the json_decode in _opening_hours_get_instance_from_request() is failing to properly set this field to a literal PHP type NULL. Probably because the client side is setting this to a string anyway ( JS also has a type null which is what should be in the JSON I'm guessing?). I think this is a separate issue to be fixed in other places but I've included a combined patch (opening_hours--bad-db-api-and-request-value-check.patch) that includes this workaround fix plus another patch I've attached in issue #1844564 for convenience. The module should be better testing some of the values before doing a drupal_write_record() but with this patch the module so far appears to be fully functional for me.
| Comment | File | Size | Author |
|---|---|---|---|
| opening_hours--bad-db-api-and-request-value-check.patch | 5.25 KB | magicmyth | |
| opening_hours--bad-db-api-calls.patch | 2.51 KB | magicmyth |
Comments
Comment #1
miklThanks for your help – I did fix the repeat_end_date in a different way, though, namely by avoiding casting the null value to a string in the first place, but it should have the same effect :)
Comment #2
miklAnyways, committed.
Comment #3
miklFix released: http://drupal.org/node/1854494