hi,
after updating to 1.7 version by drush upc, i had this warning :
Division by zero password_policy.install:360
actually
$sandbox['password_count'] = db_query("SELECT COUNT(pid) FROM {password_policy_history}")->fetchField();
is returning 0 as there is no password in the database yet for me.
so
$sandbox['#finished'] = $sandbox['password_from'] / $sandbox['password_count'];
is currenty deviding by 0
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | password_policy-division_by_zero-2289023-7.patch | 568 bytes | aohrvetpv |
| #5 | password_policy-division_by_zero-2289023-5.patch | 563 bytes | aohrvetpv |
| #3 | password_policy-division_by_zero-2289023-3.patch | 562 bytes | aohrvetpv |
| #1 | password_policy-division_by_zeor-2289023-1.patch | 3.34 KB | izus |
Comments
Comment #1
izus commentedhi,
here is a patch for this.
Thanks
Comment #2
aohrvetpv commentedThanks for reporting it and for the patch.
I don't think there are any problems caused by the update failing, but we should probably do another release soon to include this fix.
Comment #3
aohrvetpv commentedHere is a patch that fixes it in another way. I prefer this way because it only changes a line and keeps the update code easy to diff against
user_update_7000(). Also I think patch in #1 might perform a query for each execution ofpassword_policy_update_7102()(it is a batch API function so it gets invoked multiple times).Comment #4
aohrvetpv commentedWhoops, that patch was wrong...
Comment #5
aohrvetpv commentedNew patch for 7.x-1.x. 7.x-2.0-alpha2 also has this bug, and the same change should fix it.
Comment #6
aohrvetpv commentedAgain the patch is wrong...
Comment #7
aohrvetpv commentedOK, this one is better tested. I tested two cases:
1. No entries in {password_policy_history} => no division by zero error
2. Enough entries in {password_policy_history} to require multiple batch chunks => all password hashes converted
Comment #9
aohrvetpv commented