Comment voir les messages d'erreur lorsque j'obtiens l'écran blanc de la mort?

25

Comment puis-je voir les messages d'erreur lorsque le site sur lequel je travaille reçoit un écran blanc?

wsod

— sokratis
source

33

Mettez cela au bas de settings.php:

error_reporting(-1);  // Have PHP complain about absolutely everything 
$conf['error_level'] = 2;  // Show all messages on your screen, 2 = ERROR_REPORTING_DISPLAY_ALL.
ini_set('display_errors', TRUE);  // These lines just give you content on WSOD pages.
ini_set('display_startup_errors', TRUE);

— Mike
source

C'est idéal pour les sites de développement, mais je préfère /var/log/apache2/error.log pour les sites en direct. Cela fonctionne cependant. :)

— Citricguy

17

La ressource Écran blanc de la mort (page complètement vierge) sur drupal.org vous guidera à travers les étapes pour voir le message d'erreur ainsi que les problèmes courants qui les provoquent.

Erreurs "invisibles"

Si le rapport d'erreurs est désactivé, vous pouvez obtenir une erreur fatale mais ne pas la voir. Sur un site de production, il est courant que le rapport d'erreurs soit désactivé. Si tel est le cas et que PHP a rencontré une erreur irrécupérable, ni une erreur ni un contenu ne seront affichés, vous vous retrouvez donc avec une page complètement vierge.

Ce que vous pouvez faire à ce sujet est d'activer le rapport d'erreurs PHP afin qu'il affiche un message sur la page elle-même, ou de vérifier vos fichiers journaux (depuis le serveur) pour rechercher l'erreur. La procédure à suivre est expliquée ci-dessous.

Activer le rapport d'erreurs

Bien qu'il puisse être désactivé sur les hôtes commerciaux et les sites de production (pour une bonne raison, afin que les utilisateurs ne voient pas les erreurs), ces erreurs sont l'un de vos meilleurs outils de dépannage. Pour activer le rapport d'erreurs, modifiez temporairement votre fichier index.php (normalement situé dans votre répertoire racine) directement après la première balise PHP d'ouverture (ne modifiez pas les informations du fichier réel!) Pour ajouter ce qui suit:
error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);
Vous pourrez maintenant voir toutes les erreurs qui se produisent directement sur l'écran. Les problèmes de mémoire ne sont peut-être toujours pas affichés, mais c'est la première étape d'un processus d'élimination.

Si vous utilisez une configuration multisite et que vous souhaitez que des erreurs apparaissent pour un seul site, vérifiez d'abord le nom de l'hôte comme dans:
if ($_SERVER['HTTP_HOST']==='some.domain.name.here') {
  error_reporting(E_ALL);
  ini_set('display_errors', TRUE);
  ini_set('display_startup_errors', TRUE);
}
Si le problème se produit lors de l'exécution de update.php, ouvrez update.php dans un éditeur de texte et décommentez la ligne suivante:
ini_set('display_errors', FALSE);

— iStryker
source

10

Jetez un œil au journal des erreurs Apache, dans Ubuntu, il se trouve /var/log/apache2/error.logafin que vous puissiez faire:

tail -f /var/log/apache2/error.log

— tostinni
source

2

sudo tail -f /var/log/apache2/error.log

— Citricguy

1

si vous avez plusieurs vhosts avec des fichiers journaux personnalisés pour chacun d'eux, utilisez simplement ceci: sudo tail -f /var/log/apache2/*.log puis actualisez la page qui se termine par wsod

— izus

2

J'ai trouvé un moyen facile de localiser les erreurs WSOD en exécutant l'ensemble du site via drush, par exemple:

drush rs

Après cela, accédez au site à la nouvelle adresse indiquée (par exemple 127.0.0.1:8080), puis essayez de reproduire le problème, et vous verrez toutes les erreurs sur l'écran du terminal. Pas besoin de reconfigurer votre PHP, surtout en cas d' display_errorséchec (par exemple MAMP).

Je l'ai trouvé autrement en utilisant des débogueurs, par exemple:

OS X:

sudo dtruss -fn httpd 2>&1 | grep -i error

Linux:
```
sudo strace -f $(pgrep -fn httpd) 2>&1 | grep -i error
```
Remarque: changez httpden phpsi vous utilisez drush rscomme ci-dessus.

Ou installez l' XDebugextension PHP et générez un fichier de trace ( xdebug.auto_trace=1).

— kenorb
source

1

Vous, monsieur, sauvez des vies. Aucune des absurdités des paramètres php changeants n'a fonctionné pour moi, mais cela a fait l'affaire!

— Greg Somers

1

Si vous utilisez drush, vous pouvez voir des messages d'erreur à l'aide de la commande drush-ws.

— Manikandan
source

0

Je viens de changer la valeur variable $ update_free_access de FALSE en TRUE et d'exécuter le fichier update.php. Cela a résolu mon problème.

— Saeed Afzal
source

0

Vous pouvez modifier index.php et terminer le code avec un try / catch. Comme ça:

try {
    define('DRUPAL_ROOT', getcwd());
    require_once DRUPAL_ROOT . '/includes/bootstrap.inc';
    drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
    menu_execute_active_handler();
} catch (Error $t) {
    error_log('Error at Line:' . $t->getLine() . ' File: ' . $t->getFile() . ' Message:' . $t->getMessage() );
    print '<div>Message: ' . $t->getMessage() . '</div>';
    print '<div>File:' . $t->getFile() . '</div>';
    print '<div>Line:' . $t->getLine() . '</div>';
}

Le message d'erreur affichera le fichier et la ligne de code qui ont provoqué l'erreur.

— Trincer
source