Pages blanche dans l’espace privé (2.1.10)

FAT78

Juin 2011

Gros pb qui apparait sous 2.1.10 depuis qq jours : de retour dans l’espace privé sur une rubrique ou un article nouvellement créé, la page s’affiche TOTALEMENT BLANCHE (parfois le rectangle en haut à droite avec le n° de la rubrique ou article s’affiche, mais c’est tout : sur le dernier site créé, je viens d’avoir trois cas de ce type sur plus de 100 rubriques et articles créés. Les manips suivantes n’ont rien produit :
– vider les caches
– écrire les lignes "PHP 1" et "SetEnv PHP_VER 5" dans .htaccess
Ces éléments restent présents dans l’arborescence du site : les articles "invisibles" je peux les déclarer"à la poubelle" mais les rubriques, même vides, je ne peux pas les effacer ... il n’y a plus de boutons sur leur page d’admin. Le reste du site parait fonctionner normalement.
La version de spip est la dernière (17657) installée sur les pages perso free.fr
J’utilise spip depuis la 1.9 ... j’en suis à mon n-ième site spip et je n’avais pas encore vi ça ...
Si qqun connait un remède ... merci d’avance !

SPIP 2.0 Documents

Par note Par date Par date chronologique

Indiquez l’intérêt que vous portez à cette réponse

0

Suske

Juin 2011

Mettre tous les plugins à jour (STEP est très pratique), vider le cache...
Indiquez l’intérêt que vous portez à cette réponse

0

FAT78

Juin 2011

Fait ... j’ai même désactivé TOUS les plugins, vidé physiquement la totalité du cache par ftp (effacé le dossier tmp) ... rien y fait !
Dans l’espace d’admin il me restent deux rubriques vides qui affichent "page blanche" et que donc je ne peux pas supprimer !
Indiquez l’intérêt que vous portez à cette réponse

0

Suske

Juin 2011

Mmm. Je ne sais que dire... Supprimer les rubriques avec phpmyadmin à défaut de mieux... Je signale le cas sur spip-dev.
Indiquez l’intérêt que vous portez à cette réponse

0

FAT78

Juin 2011

Merci Suske de signale le pb ... nobody’s perfect !
Je viens de réussir à supprimer ces rubriques vides par une manip qui peux, peut être, donner des pistes aux devs : par ftp, j’ai crée un dossier "bis" à la même adresse et j’ai installé un spip2.1.10 vierge en lui donnant la même bdd mysql ... en y entrant comme admin j’ai eu accès au site et donc aussi aux pages AFFICHEES NORMALEMENT des deux rubriques auparavant "page blanche" (effectivement vides : pas de logo, pas de descriptif, pas d’article) ... que j’ai pu effacer par la commande "supprimer la rubrique" !
Mon site est clean mais le danger de voir "page blanche" sur un nouvel article ou une nouvelle rubrique reste entier ...
Indiquez l’intérêt que vous portez à cette réponse

0

Suske

Juin 2011

On me suggère que c’est peut-être le "classique" timeout sur un upload d’image qui serait la cause de tous ces soucis. Si c’est le cas, la solution est de supprimer la ou les images incriminées (les fichiers corrompus empêchant php de terminer la construction de la page, si je comprends bien).
Indiquez l’intérêt que vous portez à cette réponse

0

FAT78

Juin 2011

Cela est possible pour les articles contenus à l’origine dans ces rubriques, articles qui donnaient "page blanche", mais qu’il a été facile de mettre à la poubelle en modifiant leur statut et/ou de déplacer par glisser/déposer dans la page d’admin "Tout le site".
Mais je confirme que les rubriques "page blanche" étaient bien vides : auraient-elles gardé mémoire (dans quel cache autre que tout ce qui est dans tmp ?) de cet état et ainsi continué à afficher "page blanche" malgré qu’elles soient vides ?
Indiquez l’intérêt que vous portez à cette réponse

0

FAT78

Juin 2011

A tous fins utiles, voici la liste des plugins actifs dans ma config :
– acces restreint 3
– cfg
– couteau suisse
– menu babbibel
– nivoslider
– smoothgallery
– spip bonux
– tablesorter

Des incompatibilités connues entre eux et/ou avec spip 2.1.10 qui pourraient provoquer le défaut ’page blanche" ?
Indiquez l’intérêt que vous portez à cette réponse

0

FAT78

Juin 2011

CA Y EST ! A défaut d’avoir la solution, je tiens la méthode exacte pour provoquer le syndrome "page blanche" : ii suffit de lancer le téléchargement d’une image en zone d’admin d’un article et de cliquer sur "Modifier l’article" pendant que le téléchargement est encore en cours. La page d’admin de l’article devient blanche et reste blanche à jamais, il ne reste plus qu’à le mettre à la poubelle !
Ce bug devrait probablement produire des effets inattendus si on change de page pendant le téléchargement des logos de rubrique ou d’article, conduisant aux "pages blanches".
Je ne l’ai pas fait exprès : j’avais lancé le téléchargement d’un jpg de 600ko dans un nouvel article et le chargement n’avançait pas (ça arrive ... surtout sur les pagesperso de free) donc au bout d’une bonne minute j’ai cliqué sur "modifier l’article" en pensant que pendant ce temps je pouvais rentrer le texte de l’article ... et boum ! Donc, c’est un vrai bug qui peut survenir dès qu’on est sur un serveur momentanément lent.
A vous de jouer ...
Indiquez l’intérêt que vous portez à cette réponse

0

FAT78

Juin 2011

Encore moi, avec une précision ... en fait c’est l’image qu’on m’a donnée à télécharger (produite sur pc par "freeplane") qui pose problème (?) et qui bloque lors du téléchargement (même en l’ayant posée par ftp dans tmp/upload) : quel problème à cette image qui parait être un normal jpg ? Comment je peux vous la transmettre ?
C’est donc en quittant la page d’admin de l’article qui n’en finit jamais de télécharger, qu’on produit un article "page blanche"
Indiquez l’intérêt que vous portez à cette réponse

0

FAT78

Juin 2011

Voilà ... l’image incriminée est ici :
http://educeco.free.fr/debug/EE11_bilan_details.jpg
Merci d’avance pour votre aide
Indiquez l’intérêt que vous portez à cette réponse

0

FAT78

Juin 2011

Encore un pas en avant ...
Je viens de découvrir dans Configuration/ Fonctions avancées/ Méthode de fabrication des vignettes, que en cliquant sur gd1 ou gd2, apparait en bas de la fenêtre une limite d’environ 6Mpx aux images traités par spip (au bout de 10ans de spip on en découvre encore !) : mon image qui bloque fait justement dans les 6Mpx ! Alors je l’ai reduite à moins de 3Mpx et ... miracle elle est maintenant téléchargeable dans un article nouvellement créé !
J’ai donc pu l’insérer dans le texte en <embxxx> et au moment de l’enregistrement voilà un beau mlessage :
Fatal error : Allowed memory size of 33554432 bytes exhausted (tried to allocate 2000 bytes) in /mnt/104/sda/1/2/educeco/ecrire/inc/filtres_images_lib_mini.php on line 617
Pas fini les surprises ... maintenant le nouvel article affiche "page blanche" !!! Donc, je retire tout ce que j’ai dit de mal de free et je m’en excuse : le problème me parait bel et bien découler d’un bug de spip. C’est grave, docteurs ?
Indiquez l’intérêt que vous portez à cette réponse

0

Suske

Juin 2011

Pas vraiment un bug... Tout cela est lié à la configuration du serveur.

C’est ce que j’évoquais en parlant de "timeout sur un upload d’image"... Quand l’écriture de fichier image se termine mal sur le serveur pour une raison ou une autre (taille de fichier trop importante, temps de calcul serveur trop long...), à chaque tentative de l’ouvrir ça plante.

Le problème est connu mais je sais pas si ce sera traité spécifiuement vu qu’il y a moyen de limiter la taille des images avec une constante SPIP : voir Variables et constantes en bas à droite de l’index de spip.net (http://www.spip.net/@).
Indiquez l’intérêt que vous portez à cette réponse

0

FAT78

Juin 2011

Bon ... n’appelons pas ça un bug ... disons que c’est un problème apparemment connu ... et auxquels les devs n’ont pas de parade ? Un timeout pour éviter de générer "page blanche" ... svp ?
Parce que la solution de limiter les dimensions par mes_options.php est carrément contraire à l’esprit de spip, au moins sous l’aspect "site rédactionnel collaboratif" : divers rédacteurs vont alimenter le site ... ce sont des rédacteurs, pas des informaticiens ... ils vont amener parfois des images trop grosses ... j’aurai bon les prévenir de ne pas dépasser certaines limites ... parfois il vont l’oublier ... si le site refuse leur téléchargement, c’est pas grave (quand l’image dépasse les 2Mo, le rejet se passe bien) ... mais s’il tourne en boucle sans fin et qu’ils perdent leur rédaction, je vais les entendre ... et ils n’auront pas tort !
Et même, quelles limitations imposer ? J’ai découvert le piège parce que un des rédacteurs n’arrivait pas à insérer une image de 600ko mais dont la hauteur (4400px) bloquait ; ils ont souvent des panoramiques qui tiennent en dessous des 2Mo réglementaires mais qui vont peut être bloquer ... je leur raconte quoi ? Avec un peu de chance ça passe, avec pas de chance ... "page blanche" et leur rédactionnel perdu ?
Non, vraiment, un système de timeout serait le bienvenu : il vaut mieux rejeter à tort mais proprement un téléchargement, que de générer la "page blanche" qui fait perdre le travail déjà effectué.
S’il vous plait ...
Indiquez l’intérêt que vous portez à cette réponse

0

Suske

Juin 2011

Du calme, du calme. Rien n’est contraire à l’esprit de SPIP ici dedans !?

Perso j’ai un dédié qui supporte très bien les images jusqu’à 8,5Mb et qui accepte sans broncher les 4400pixels. C’est une question de configuration du serveur. Oui, il serait probablement possible de programmer des tas de tests qui permettent de mieux prévenir les rédacteurs etc. Enfin je suppose. Je ne sais pas faire ça sinon je ne serais pas ici... Chacun prend sa place en fonction de ses compétences et limites. Il est plus simple de dire "il vaut mieux faire ceci" que de le programmer...

Ce n’est pas fait. Mais ce qui est fait, c’est de définir des constantes qui permettent au webmestre d’adapter la configuration de SPIP aux limites du serveur. Elles sont documentées là où je t’ai écrit d’aller voir. Si tu les définis, SPIP rejettera les fichiers qui les excèdent. Donc, tu fais des tests sur les images, leur taille, leurs dimensions. Tu prends une marge de sécurité de 10% (par ex.) et tu limites la taille, le poids...

Après, je connais pas tout de SPIP et s’il y a d’autres bonnes solutions, d’autres viendront peut-être les donner...
Indiquez l’intérêt que vous portez à cette réponse

0

FAT78

Juin 2011

Voilà, j’ai suivi tes conseils avisés et j’ai récupéré le fichier mes_options.php donné en exemple sur spip.net, j’y ai mis les lignes relatives aux limites de largeur et de hauteur (2450x2450px) et je l’ai installé dans /config. (c’est une première pour moi, je n’y connais rien en php)
Dans un article de test, j’ai essayé de télécharger une image de 2500x1250px et la protection a fonctionné en affichant :
"Les logos doivent obligatoirement faire moins de 2450 x 2450 pixels (ce fichier fait 2500 x 1250 pixels)"
et en rendant la main proprement. Pas de "page blanche" ... c’est bon !
Intrigué par le message affiché, j’ai téléchargé ce même fichier comme logo de l’article et là, surprise ... l’image est chargée, spip en fait une vignette qui s’affiche comme logo et indique bien 2500 x 1250 pixels !
Donc la protection ne fonctionne pas sur les logos et si j’avais chargé comme logo une image de plus de 3000px j’aurai eu "page blanche" et perdu l’article.
Deux questions, please :
– quelle ligne de code faut-il ajouter afin que la protection de mes_options.php fonctionne aussi sur les chargements des images pour les logos d’article et de rubrique ?
– dans quel fichier pourrais-je modifier le texte du message d’alerte (je voudrais mettre "Les images doivent obligatoirement ..." au lieu de "Les logos doivent etc.").
Merci d’avance !
Indiquez l’intérêt que vous portez à cette réponse

0

Gaelle

Juillet 2011

Personnellement en vidant le cache j’ai récupéré l’espace privé normal. Si ça peut aider quelqu’un !
Indiquez l’intérêt que vous portez à cette réponse

0

isadav

Juillet 2011

je n’arrrive plus à modifier un article en cours de rédaction. la page de mo, espace privé est blanche.
J’avais rajouter des signes typographiques dans la ligne de titre