Magento: debug des pages blanches

Il arrive parfois que sur Magento, on se retrouve avec une page blanche, sans erreur, sans log. C’est souvent dû à un problème avec les Layouts qui ne génère jamais d’erreur.

Pour trouver la source du problème, il faut donc afficher une erreur. Après quelques recherches sur notre ami G*****, j’ai trouvé deux solution complémentaire, il suffit d’exécuter le code suivant avant notre code exécuté, dans mon cas je l’ai inséré dans la fonction du module.

Afficher les erreurs PHP lié au manipulation des Layouts :


// —————————————————————————————————-
// – Display Errors
// —————————————————————————————————-
ini_set(‘display_errors’, ‘On’);
ini_set(‘html_errors’, 0);

// —————————————————————————————————-
// – Error Reporting
// —————————————————————————————————-
error_reporting(-1);

// —————————————————————————————————-
// – Shutdown Handler
// —————————————————————————————————-
function ShutdownHandler() {
if (@is_array($error = @error_get_last())) {
return(@call_user_func_array(‘ErrorHandler’, $error));
};

return(TRUE);
}

;

register_shutdown_function(‘ShutdownHandler’);

// —————————————————————————————————-
// – Error Handler
// —————————————————————————————————-
function ErrorHandler($type, $message, $file, $line) {
$_ERRORS = Array(
0x0001 => ‘E_ERROR’,
0x0002 => ‘E_WARNING’,
0x0004 => ‘E_PARSE’,
0x0008 => ‘E_NOTICE’,
0x0010 => ‘E_CORE_ERROR’,
0x0020 => ‘E_CORE_WARNING’,
0x0040 => ‘E_COMPILE_ERROR’,
0x0080 => ‘E_COMPILE_WARNING’,
0x0100 => ‘E_USER_ERROR’,
0x0200 => ‘E_USER_WARNING’,
0x0400 => ‘E_USER_NOTICE’,
0x0800 => ‘E_STRICT’,
0x1000 => ‘E_RECOVERABLE_ERROR’,
0x2000 => ‘E_DEPRECATED’,
0x4000 => ‘E_USER_DEPRECATED’
);

if (!@is_string($name = @array_search($type, @array_flip($_ERRORS)))) {
$name = ‘E_UNKNOWN’;
};

return(print(@sprintf(« %s Error in file \xBB%s\xAB at line %d: %s\n », $name, @basename($file), $line, $message)));
}

$old_error_handler = set_error_handler(« ErrorHandler »);

 


Créer un log qui contient la requête, l’action du controller, les handles (nameSpace des templates) qui sont appelés, ainsi que le XML du layout qui va être chargé, à insérer dans le code de votre fonction :


$this->loadLayout();

$req  = Mage::app()->getRequest();
$info = sprintf(
« \nRequest: %s\nFull Action Name: %s_%s_%s\nHandles:\n\t%s\nUpdate XML:\n%s »,
$req->getRouteName(),
$req->getRequestedRouteName(),      //full action name 1/3
$req->getRequestedControllerName(), //full action name 2/3
$req->getRequestedActionName(),     //full action name 3/3
implode(« \n\t »,$this->getLayout()->getUpdate()->getHandles()),
$this->getLayout()->getUpdate()->asString()
);

// Force logging to var/log/layout.log
Mage::log($info, Zend_Log::INFO, ‘layout.log’, true);


Sources :

  • http://magento.stackexchange.com/questions/95/debugging-layout-loading
  • http://stackoverflow.com/questions/1475297/phps-white-screen-of-death

Magento : Problème lors du process d’indexation sur les produits de la catégorie

Le problème est survenu lors d’un import/export de produit de la préproduction vers la production.
Avec l’erreur suivante dans les exceptions :

SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`MABASE`.`catalog_category_product_index`, CONSTRAINT `FK_CAT_CTGR_PRD_IDX_CTGR_ID_CAT_CTGR_ENTT_ENTT_ID` FOREIGN KEY (`category_id`) REFERENCES `catalog_category_entity` (`en)

Le problème vient d’une catégorie qui n’existait plus. Pour résoudre le bug, il suffit d’exécuter la requête suivante :


SELECT * FROM catalog_category_product
WHERE category_id NOT IN
( SELECT entity_id FROM catalog_category_entity )

Cette requête permet d’extraire toutes les lignes qui concernent une catégorie qui n’existe plus.
Il suffit de supprimer toutes ces lignes et de lancer la réindexation en administration Magento.

Vider le dossier session de magento

Créer le fichier de batch en étant connecté sur le ssh grâce à la commande :

vim session_cleanup.sh

Ensuite écrire le code suivant dans le fichier :

#!/bin/sh
find chemin/vers/le/fichier/var/session/ -name 'sess_*' -type f -mtime +1 -exec rm -rf {} \;

Explications :

  • #!/bin/sh : Définir le type de script qui est utilisé.
  • /home/hifissimo/public_html/www.hifissimo.com/var/session/ : chemin vers votre dossier de session du le serveur.
  • -name ‘sess_*’ : le nom de fichier ou dossier recherché.
  • -type f : le type (dossier / fichier …).
  • -mtime +1 : la date supérieur à 48h.
  • -exec rm -rf {} \; : on lance la commande de suppression sur les résultats.

Url de la doc du find : http://pwet.fr/man/linux/commandes/find

Puis il faut ajouter les droits d’exécution du fichier sh :

chmod u+x chemin/vers/le/fichier/session_cleanup.sh

Ajouter le fichier dans les cron :

crontab -e

t

0 3 * * * /chemin/vers/le/fichier/session_cleanup.sh