Bug de comportement de la fonction `objet_modifier_champs()` en 4.1+ : les valeurs null sont ecrasées en base
La fonction objet_modifier_champs()
a changé de comportement en 4.1+ quant aux valeurs nulles envoyées dans le tableau $c
https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/modifier.php#L99
Les entrées ayant une valeur nulle était ignorée jusqu'à SPIP 4.0.
En SPIP 4.1+, la valeur nulle est conservée dans le tableau associatif, et le passage dans corriger_caracteres()
la transforme en chaine vide, qui est envoyée en base et écrase donc la valeur existante.
Le bug vient d'un refactoring. On avait avant https://git.spip.net/spip/spip/src/branch/4.0/ecrire/inc/modifier.php#L144 les lignes
// N'accepter que les champs qui existent
// TODO: ici aussi on peut valider les contenus
// en fonction du type
$champs = [];
foreach ($desc['field'] as $champ => $ignore) {
if (isset($c[$champ])) {
$champs[$champ] = $c[$champ];
}
}
qui ont été refactorées en https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/modifier.php#L143
$champs = array_intersect_key($c, $desc['field']);
Le premier s'appuyant sur un isset()
qui renvoie false sur les valeurs nulles, le second utilisant la fonction array_intersect_key()
qui se contente de filtrer les valeurs de $c
qui n'ont pas une entrée dans $desc['field']
Le bug n'est en général pas visible sur les formulaires d'édition des objets, car la fonction collecter_request()
utilisée en amont pour collecter les variables postée ignore les valeurs nulles.
Mais avec les crayons, la fonction crayons_recupere_post()
n'ignore pas les valeurs nulles et les récupère dans le tableau associatif
https://git.spip.net/spip-contrib-extensions/crayons/src/branch/master/action/crayons_store.php#L61
elles finissent par arriver dans objet_modifier_champs()
qui écrase alors les valeurs en base