un cas très particulier, je ne sais pas si ça mérite un ticket : un spip 3.1, configuré avec image_process = gd2
Je modifie la config de php ou j'en utilise une autre version, avec la librairie gd qui n'est plus activée.
Je relance apache, je retourne sur le site : pages blanches partout.
Je supprime la valeur de image_process dans spip_meta, ça revient.
C'est vraiment très particulier, mais ça pourrait arriver si on déplace une base mysql (sûrement pareil avec sqlite) d'une config à une autre.
Oui bien sûr tu dois pouvoir enrober le test de choix de librairie graphique avec un test d’existence de cette librairie. C’est ce qu’on fait dans memoization par exemple.
J’ai eu un cas pareil sur un serveur sans gd2.
SPIP ne fonctionne pas sans, car de nombreux filtres graphiques ont besoin de cette librairie. Il faudrait donc bloquer l’installation lorsque gd2 n’est pas détecté
D’ailleurs je ne sais pas si l’installation est bloqué si on n’a pas php5.1 – bon, c’est pas aujourd’hui qu’on va réfléchir à ça
Ces meta là sont attachés à l'hebergement, et du coup ne sont pas importées quand tu backup/restore sur un autre SPIP.
Evidement dans le cas où l'hebergement change lui même ou si tu fais un dump mysql à la mano, il faut gérer ce cas manuellement en repassant dans la config, on ne va pas faire de la detection à chaque hit pour un cas très hypothétique
Calomnie. Justement le core et squelettes-dist fonctionnent sans GD2, et ne veillent à utiliser que les filtres génériques (en gros reduction de taille d'image) qui sont multi-implémentés.
Ensuite il est clair que tous les filtres d'image avancés nécessitent GD2 si on les utilise. C'est donc au niveau de ce plugins-dist qu'il faudrait traiter cette dépendance.
Ok, donc tu confirmes que c'est bien un cas très particulier, qui peut arriver à des utilisateurs qui savent un minimum ce qu'ils font. Pas nécessaire d'en faire un ticket.
Je suis en plein tests d'install/recompilations de plusieurs versions de php à la volée, ça n'arrive pas tous les jours.
D'un autre côté, ce qui m'a surpris c'est la page blanche énigmatique, même avec un error_reporting ALL et display_errors 1 dans mes_options, (et pas de logs non plus). Ça doit mourir silencieusement quelque part, mais bon, c'est peut être pas très grave non plus.
Oui pardon, je n’avais pas précisé que tous les filtres graphiques ne dépendent pas de gd2
Par contre, différencier pour le coup le core des plugins-dist me parait léger, et je ne suis pas convaincu que les filtres sensibles ne soient pas utilisés dans l’interface privée (j’avais un plantage sur la partie centrale de la page d’accueil). De toute manière, un hébergement sans gd2 est une absurdité.
Pour info, on a encore eu un cas sur IRC (bertrandbbb).
Suite à un apt-get upgrade de Debian, le paquet php5-gd n'était plus installé et le site affichait des pages blanches dès qu'une image était présente (articles, flux rss), et plus d'accès au privé.
Tout ça de façon silencieuse : pas de message d'erreur, rien dans les logs apache ou spip.
Un truc à devenir dingue, il y a passé plusieurs heures, mais je me suis souvenu de ce problème.
Il y a un truc à vérifier peut-être aussi : même si gd est installé, on n’a pas forcément toutes les fonctions dans la version “embarquée”.
En particulier sous Ubuntu php5-gd ne contient pas les fonctions imagerotate et imageantialias http://nossie.addicts.nl/php5-gd.html
En l'occurence, un phpinfo indiquait bien le module GD actif (en version 2), mais après avoir relancé son site (suppression de image_process dans spip_meta) il n'y avait pas l'option GD dans les fonctions avancés.
Il a dû faire un apt-get install php5-gd pour rétablir.
Mais bon, ça c'est peut être lié à la gestion des paquets de Ubuntu, je me souviens avoir déjà eu une merde avec ça.
Reste ce problème de SPIP qui meurt en silence dans ces cas là, et que c'est un truc à s'arracher les cheveux quand ça arrive.
Marcimat avait corrigé quelque chose là dessus, c'était en 3.0 ou 3.1 ?
Un test, il me semble, qui évitait de mourir en silence.
le problème est général à toutes les fonctions gd qui en effet meurent en silence en cas d'echec (que ce soit par absence ou par dépassement mémoire ou autre) sans aucun log PHP ni même générer une erreur Fatale.
Les erreurs ne sont même pas catchables, et je m'étais arraché les cheveux pour faire detecter les echecs dans le test des images de taille maxi qu'on peut manipuler.
En résumé la seule solution fonctionnelle que j'avais trouvé c'est un d'ouvrir un tampon avec une fonction handler en sortie https://core.spip.net/projects/spip/repository/entry/spip/ecrire/action/tester_taille.php#L111
et de lever une globale avant d'appeler la fonction GD, qui permet dans le handler de savoir qu'on a échoué dans la fonction GD.
Il faut ensuite rebasculer la globale juste après l'appel à la fonction GD, car le handler sera de toute façon appelé en fin de tampon, donc il faut qu'il sache qu'il n'y a pas eu d'erreur.
On pourrait faire une fonction helper du genre
function gd_safe_call($fonction_gd,...){
}
qui se chargerait de tout cela : ouvrir le tampon avec un handler, lever la globale, faire un call de la fonction gd et gerer la sortie propre en cas de succes ou la sortie sale via le handler qui permettrait au moins d'ecrire un log en cas d'echec (et peut-être un message a l'ecran si on est connecte ?), mais en aucun cas de continuer le hit normalement.
A voir si c'est lourd a faire ou acceptable, y compris en terme de temps d'execution.
