Traquer les erreurs dans WordPress

Il ne s’agit pas ici de chercher les bugs de WordPress, mais bien comment trouver vos erreurs.

Lorsque vous fabriquez des thèmes ou des extensions persos…

Préambule

Cet article est écrit après la lecture de How to Debug WordPress Beyond the Basics, en anglais. Qui a puisé l’essentiel de son contenu (pas que) dans l’incontournable documentation de WordPress bien sûr.

Et basé aussi sur mon expérience de créateur de bugs… euh… de développeur/formateur WordPress. Où mes élèves créent des bugs. Bon, les mêmes bugs que j’ai créé moi même, et qu’il m’arrive de créer encore. Ou pas forcément les mêmes… Bref.

Donc, qui dit créer du code dit créer des erreurs, donc les traquer et les éliminer. Ouf.

Créer des erreurs

Celles-ci sont intentionnelles… C’est pour voir le comportement…

Ajoutons dans notre fichier de thème ces deux lignes:

<?php
     print(1 / 0);
     montre_moi_mon_erreur();
?>

Sans appel.

WordPress s’arrête, et un panneau assez neutre nous indique que cela ne marche plus. Ainsi que le fameux lien vers la documentation.

Premier outil de debug, le fichier de configuration, c’est à dire wp-config.php, situé à la racine de l’installation de WordPress.

On va pouvoir y ajouter des lignes pour activer des tests.

Attention: fichier sensible s’il en est, il est important de ne pas le casser sinon votre WordPress explose en petits morceaux, façon puzzle.

Le fichier est souvent créé au moment de l’installation, il faut donc le rapatrier avant modification si besoin.

Une constante…

Vers le bas du fichier, une constante est définie:

define('WP_DEBUG', false);

Il suffit de la passer à true pour activer le mode debug.

Le message est beaucoup plus explicite bien entendu…

Et distingue Warnings (avertissement) qui ne gênent pas trop WordPress en temps normal (ne laisser que la division par zéro n’empêchera pas WordPress de fonctionner, mais affichera INF, donc l’infini) et Fatal Error (erreur fatale, si…) qui elles sont bloquantes.

Limitée à soi même

Bien sûr, le mode debug est intéressant, mais assez polluant car, sur un site en exploitation, le visiteur verrait la même chose.

On peut donc limiter l’affichage version longue à la personne faisant le débuggage, et laisser la version courte aux visiteurs.

if ("123.45.67.89" === $_SERVER["REMOTE_ADDR"]) {
    define('WP_DEBUG', true);
} else {
    define('WP_DEBUG', false);
}

En remplaçant les numéros par votre adresse IP à vous…

On ne peut pas se baser sur le fait qu’on soit administrateur car, au moment du chargement du fichier config, nous ne sommes pas encore connecté.

Mais ce test peut servir ailleurs pour tester des fonctions:

if( current_user_can('administrator') ) {
    // réservé aux administrateurs}
}

if ("123.45.67.89" === $_SERVER["REMOTE_ADDR"]) {
    define('WP_DEBUG', true);
    define('WP_DEBUG_LOG', true);
    define('WP_DEBUG_DISPLAY', false);
    @ini_set('display_errors', 0);
    define('SCRIPT_DEBUG', true);
    define('SAVEQUERIES', true );
} else {
    define('WP_DEBUG', false);
}

Dans l’ordre:

• WP_DEBUG pour activer le mode debug
• WP_DEBUG_LOG pour créer un fichier debug.log dans le dossier wp-content, qui contient le texte des erreurs (voir image ci dessous)
• WP_DEBUG_DISPLAY (à false) pour ne pas afficher les erreurs WordPress
• ini_set pour demander à php de ne pas afficher les erreurs
• SCRIPT_DEBUG pour utiliser les versions non minifiées des css et js de WordPress (à mon avis, sert peu)
• SAVEQUERIES enregistre les requêtes SQL de la base de données dans un tableau

Le fichier de log

Le fichier généré ressemble à ceci:

Il reprend les erreurs sus-nommées, mais ne les affiche pas…

L’article de WPShout complète l’info en spécifiant que, dans vos fichiers à vous, vous pouvez également exploiter ce fichier de log (s’il est activé bien sûr) pour y glisser vos propres messages…

Ainsi:

<?php
   error_log("message pour moi...");
?>

Ajoutera dans le fichier:

[05-Feb-2021 08:16:55 UTC] message pour moi...

Pour des messages plus complexe (des variables par exemple) on peut utiliser:

<?php
    ob_start(); // capture les affichages php
    print_r($wpdb->queries); // affiche une variable structurée
    $contents = ob_get_contents(); // récupère les affichages
    ob_end_clean(); // vide le buffer
    error_log($contents); // envoie vers le fichier de log
?>

Et donc notre fichier:

(je n’ai mis que les 12 premières lignes, la génération d’une simple page en ayant généré presque 125…)

On fait le ménage

Bien sûr, une fois l’opération de traque terminée, pensez à:

• re-modifier le fichier wp-config pour désactiver le mode de test
• supprimer le fichier debug.log qui risque de grossir très vite
• retirer les lignes utilisant error_log (même si, à priori, le fait de désactiver la constante semble l’empêcher de marcher…)

Et pour les « fainéants » ?

Comme souvent avec WordPress, des extensions existent qui permettent de se simplifier la vie, y compris en mode traque d’erreur…

• Debug Bar, ajoute un menu de débogage à la barre d’administration qui affiche la requête, le cache et d’autres informations de débogage utiles
• Debug This, fournit une tonne d’informations sur votre installation WordPress, le tout à partir de la barre d’administration.
• Query Monitor, permet le débogage des requêtes de base de données, des erreurs PHP, des hooks et des actions, des blocs d’éditeur de blocs, des scripts et feuilles de style mis en file d’attente, des appels d’API HTTP, etc.
• Show Current Template, affiche les fichiers du thème sur lequel on se trouve, dans un autre genre, mais dont je ne saurais me passer

Bon, Debug Bar et Debug This font la même chose, n’installez pas les deux…

En vous souhaitant de bons bugs!