Hop,
Juste pour signaler que sur la page https://contrib.spip.net/Plugin-Inserer-Modeles, la section 'Vos commentaires" reste bloquée sur "Chargement en cours…"
Sur les autres pages ça marche.
Cheers
Hop,
Une image .jpg qui était une TIFF à l’intérieur, dans un commentaire. Je l’ai supprimée. Un bug à corriger accessoirement.
MM.
Une image .jpg qui était une TIFF à l’intérieur, dans un commentaire. Je l’ai supprimée.
Merci 
Une image .jpg qui était une TIFF à l’intérieur, dans un commentaire. Je l’ai supprimée.
Merci
Je pense que c’est le bug que j’ai signalé récemment sur #spip
En traçant un peu je suis remonté à https://bugs.php.net/bug.php?id=73116
j’ai déjà eu le cas deux fois, il suffit qu’un fichier image soit mal passé pour que SPIP crashe, sans possibilité de catcher l’erreur… une solution est de remplacer, dans ecrire/inc/filtres_images_lib_mini.php
$srcImage = @$fonction_imagecreatefrom($image);
par
$srcImage = imagecreatefromstring(file_get_contents($image));
– Fil
Oui, tout à fait, c’est ce problème là je pense.
Cependant, cette solution tente de charger toute l’image en mémoire, ce qui risque de ne va pas fonctionner non plus dans d’autres cas ?
Cela dit, c’est aussi ce qu’ielles font :
A) dans la librairie Imagine :
Je suis presque certain d’avoir codé une detection préventive de mauvais format à l’upload, qui remet la bonne extension si jamais l’utilisateur a fait n’importe quoi.
Il faut que je retrouve ou (peut-être uniquement sur le trunk dans l’upload de documents sur le plugin medias ?)
Hop,
Ah ben voilà, et en plus c’est @marcimat qui a fait ça, pas du tout moi 
Faudrait vérifier ce qui se passe sur les images fautives quand on passe là, et voir si on peut faire mieux ou si il manque juste de les prendre en compte dans les logos ?
Hop,
Ah ben voilà, et en plus c’est @marcimat qui a fait ça, pas du tout moi
Faudrait vérifier ce qui se passe sur les images fautives quand on passe là, et voir si on peut faire mieux ou si il manque juste de les prendre en compte dans les logos ?
Pour info, j'ai testé plusieurs cas d'usage (un png déguisé en jpg et l'inverse) et à chaque fois SPIP a bien détecté la fourberie puis renommé automagiquement le fichier lors de l'upload d'un document ou d'un logo, super.
Par contre, ça ne couvre pas le problème des fichiers uploadé avant l'intégration du patch.
Je pense que c'est ce cas de figure que j'ai du observer dernièrement sur un site en 3.2.1 que je maintiens.
Donc, le patch de fil pourrait être intéressant en mode "ceinture et bretelles"
En fait cela vient d’une modification dans la librairie GD utilisée.
On trouve https://stackoverflow.com/a/42899281 qui amène à https://github.com/libgd/libgd/issues/338
Ils ont re-modifié le comportement en version 2.2.5 (pour repasser à un warning au lieu d’une erreur fatale). Mais les versions GD inférieures, notamment 2.2.4 sont impactées.
Une solution qui me paraitrait plus correcte serait de dire :
if (!$srcImage = @$fonction_imagecreatefrom($image)) {
$srcImage = imagecreatefromstring(file_get_contents($image));
}
Sauf que le @ ne fait rien avant 2.2.5 (et après je ne sais quelle version d’ailleurs), donc dans ce cas le problème fatal serait toujours présent.
On pourrait aussi tenter d’améliorer l’analyse du format source ($term_fonction) avec
$mime = finfo_file(finfo_open(FILEINFO_MIME_TYPE), $path);
Comme le fait Imagine.
MM.