Débogage de Drupal Écran Blanc de la Mort?

Je sais que cela peut être en retard, mais il m'a aidé. La plupart du temps un module causes WSOD, je ne pouvais pas, il suffit de désactiver les modules de test de laquelle il a été, depuis que j'ai peut-être perdu des données dans le processus. Ce que j'ai fait pour modifier cette fonction dans le module.inc

function module_invoke_all($hook) {
  $args = func_get_args();
  //Remove $hook from the arguments.
  unset($args[0]);
  $return = array();
  foreach (module_implements($hook) as $module) {

        print "Starting loading $module <br />";

        $function = $module . '_' . $hook;
        if (function_exists($function)) {
          $result = call_user_func_array($function, $args);
          if (isset($result) && is_array($result)) {
            $return = array_merge_recursive($return, $result);
          }
          elseif (isset($result)) {
            $return[] = $result;
          }
        }

        print "Finished loading $module <br />";

  }

  return $return;
}

Et j'ai ajouté ces 2 instructions d'impression, dans le code ci-dessus, puis actualisez la page, le module qui n'a pas atteint la "fin du chargement $module" instruction est celui avec le problème... c'était devel dans mon cas.

Après avoir trouvé le module, vous pouvez aller dans la table système et de regarder pour ce module, set status = 0 et bootstrap = 0 ou exécutez la requête:

UPDATE system SET status = 0, bootstrap = 0 WHERE name = 'module_name' LIMIT 1

Référence: Débogage Drupal Écran Blanc de la Mort (WSOD)

OriginalL'auteur Joshua Kissoon

Contenu de thème('page') le rendu est vide, et qui serait assez sûr de vous donner un WOD.

Utilisation cette pour vous aider, il trouve un couple de problèmes communs liés à WOD.

Aussi essayer de reconstruction des autorisations, le meilleur moyen est d'utiliser drush et type:

drush php-eval 'node_access_rebuild();'

Également utiliser drush à vue actuellement modules installés, avec

drush sm

désactiver TOUS les modules personnalisés, et de recherche.

drush disable <modulename>

Et pendant que vous êtes dans drush, vider le cache:

drush cc

Si vous figure cron est le problème , j'ai eu d'énormes problèmes avec mal écrit cron crochets avant, juste au cas où c'est votre problème, supercron sera votre ami pour cela.

Vous devriez avoir assez de mémoire, sauf si vous avez quelques module de là à se comporter très mal.

* Résolution des problèmes de mise à jour

Si le problème se produit lors de l'exécution update.php ouvert update.php dans un éditeur de texte et décommentez la ligne suivante:

ini_set('display_errors', FALSE);

Voir cette page pour un tas d'autres wsod correctifs. Notamment si vous utilisez le chemin d'accès de l'auto, le correctif mentionné sur cette page vaut la peine de regarder dans.

OriginalL'auteur stefgosselin

En supposant qu'il est un hôte Linux, il pourrait être un problème d'autorisations si votre hôte est en cours d'exécution suPHP ou une autre forme de suexec. Assurez-vous que le propriétaire des fichiers est correct et que le mode d'accès est correct.

Vous pouvez également avoir un invalide .fichier htaccess, essayez de l'enlever, il suffit de tester pour cela.

OriginalL'auteur Geoffrey

Avait un WSOD qui ne voulait pas me dire ce qui n'allait pas. Aucune erreur ne s'est manifesté après l'activation display_errors/display_startup_errors/error_reporting. Il n'y avait rien dans l'erreur PHP journal. Il n'y a rien dans le journal des erreurs du serveur. Juste un WSOD et aller à la figure.

La façon dont j'ai finalement réussi à l'amadouer Drupal en affichant des messages d'erreur était de permettre à $update_free_access = FALSE; et accédez à /update.php. Cela a montré qu'il n'y avait pas de mises à jour en attente, mais tout un tas d'erreurs dans la base de données, qui sont le résultat d'une foiré importation de données.

OriginalL'auteur Roman Starkov