forked from GNUsocial/gnu-social
Check profile->update() result against false exactly; we may legitimately get 0 back if no rows were changed. DB objects normally would return true, but the comparisons aren't 100% reliable when we've got numbers which could be ints or strings or floats.
Caused failures saving profile settings with Geonames plugin enabled; the lat/lon/id fields would get re-set with freshly looked up values which no longer matched the previous values as far as the data object could tell, but which saved as the same ol' numbers.
This commit is contained in:
parent
69abde6e0c
commit
f7a3e508ba
@ -323,7 +323,7 @@ class ProfilesettingsAction extends AccountSettingsAction
|
|||||||
|
|
||||||
$result = $profile->update($orig_profile);
|
$result = $profile->update($orig_profile);
|
||||||
|
|
||||||
if (!$result) {
|
if ($result === false) {
|
||||||
common_log_db_error($profile, 'UPDATE', __FILE__);
|
common_log_db_error($profile, 'UPDATE', __FILE__);
|
||||||
$this->serverError(_('Couldn\'t save profile.'));
|
$this->serverError(_('Couldn\'t save profile.'));
|
||||||
return;
|
return;
|
||||||
|
Loading…
Reference in New Issue
Block a user