Catégories:
Bonjour support,
Est-ce que l’un d’entre vous a eu à gérer un WSOD (white screen of death) ? Après vérification de tous les fichiers au niveau syntaxe et nos tests pour faire revenir un affichage du front, il semblerait y avoir un conflit au niveau de la base de données.
Merci par avance de votre aide précieuse.
- Vous devez vous identifier ou créer un compte pour écrire des commentaires
Bonjour,
Il s’agit d’une installation fraiche ou bien d’une panne sur un site qui fonctionnait déjà ?
lateral
106
Il s’agit d’un site qui fonctionnait déjà.
gudaillier
12
Des évènements marquants récemment ? L’installation d’un nouveau module ? La retouche d’un thème ? Une augmentation énorme de trafic ?
Numerizen
1822
oui
gudaillier
12
Ajout de modules oui, pas de traffic car en dev, retouche de thème oui mais vérifié à fond notamment au niveau des erreurs de syntaxe php après le ?>
Augmentation de la mémoire allouée sur php
Restauration de backup de BDD
Toujours le même symptôme : WSOD ;
Ce que je n’ai pas encore fait c’est désactiver les modules 1 à 1 pour vérifier mais ça va me prendre un temps de fou (120 modules en tout)
gudaillier
12
Je vais essayer avec drush pour la désactivation de module…
gudaillier
12
Je n’ai toujours aucun changement, j’ai toujours un WSOD HELP !!
gudaillier
12
Essayez peut-être d’activer l’affichage des erreurs php
Dans le settings.php :
ini_set(“display_errors”, 1) ;
Ou bien dans un htaccess à la racine du site : php_flag display_errors on
Ou d’augmenter la limite de mémoire dans le php.ini
Ou de vider la table de sessions et les différentes tables de cache de la base.
Blog Drupal | Twitter
Crayulayon
145
Merci pour cette suggestion !
Ou bien dans un htaccess à la racine du site : php_flag display_errors on » pas de message d’erreur au moment du WSOD :(
Ou d’augmenter la limite de mémoire dans le php.ini » déjà fait, toujours le WSOD
Ou de vider la table de sessions et les différentes tables de cache de la base. » déjà fait, toujours le WSOD
gudaillier
12
J’ai remarqué que je faisais partir le WSOD en mettant à jour les données de la table ‘system’ par celles d’une même version mais sans WSOD. Lorsque je fais une manip en admin, le wsod revient et je fais une MAJ de la table ‘system’ pour faire revenir l’affichage.
J’ai comparé les tables ‘system’ avant et après WSOD pour voir d’où vient l’anomalie mais le problème est que je ne vois pas d’où vient l’anomalie…
Il semblerait y avoir conflit au niveau de la gestion de modules et thèmes…
gudaillier
12
Firebug montre-t-il des erreurs dans l’onglet Réseau ? Regarder les lignes en rouge. Je parierais qu’il y en a une qui dit «Error 500 : Internal server error»
Numerizen
1822
Non, malheureusement je ne vois rien de la sorte dans la console… Au moment du WSOD, j’ai juste un texte banal qui indique le nom d’une région du template, dans le code HTML un tag qui mentionne le module context dans le nom de la class et puis c’est tout.
ex : ‘<’a id=»context-block-region-left» class=»context-block-region»’>’ Left sidebar ‘<’/a’>’
Est-ce que ce serait context qui serait propice à faire crasher le site ?
gudaillier
12
Bon, arrivé à ce point, il va être difficile de vous aider sans voir le site. Vous pouvez m’envoyer une URL par message privé si vous voulez.
Numerizen
1822
En fait, je m’aperçois que j’ai surtout des WSOD en étant connecté en admin et en contributeur, jamais, aussi bien qu’en utilisateur anonyme.
J’arrive temporairement à dégager un WSOD en faisant un truncate de la table ‘system’ et en remplaçant les données d’une autre version de la table system n’ayant pas eu de WSOD avant son dump.
Qu’est ce qui peut expliquer cette différence entre un admin et un contributeur qui n’a pas de WSOD ? Au niveau des droits ? Ce qui expliquerait que le contributeur n’ait pas déclenché un script douteux qui fait un WSOD ?
gudaillier
12
Eh bien, c’était un simple module qui en était la cause : popup filter ! Ce module mal codé, était mal désinstallé et foutait un bronx sans nom dans la table system.
Plus de WSOD, plus de cauchemar…
gudaillier
12