Dans WordPress, pour afficher les erreurs, il faut ajouter plusieurs constantes dans le fichier wp-config.php

Mise en place du mode debug

// Debug mode
define('SAVEQUERIES', true);
define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', true);

« SAVEQUERIES » permet de sauvegarder les requêtes de la base de données dans un tableau : $wpdb->queries (plus d’informations ici).

« WP_DEBUG » permet simplement d’activer ou non le mode debug.

« WP_DEBUG_DISPLAY » permet d’afficher ou non à l’écran les erreurs (plus d’informations ici).

Évidemment, une fois le site en ligne, il ne faut plus afficher les erreurs, mais les conserver dans un fichier afin de pouvoir intervenir si un problème survient.

Pour ce faire, il faut avoir un fichier de config différent en fonction de l’environnement (development, staging, production, etc.).

Mise en place d’un système d’environnement

Par exemple :

if (file_exists('prod')) {
    require_once 'production.php';
} elseif (file_exists('staging')) {
    require_once 'staging.php';
} else {
    if (file_exists('development')) {
        require_once 'development.php';
    } else {
        die("Problème de configuration");
    }
}

Dans le fichier wp-config.php, il faut juste tester si par exemple un fichier (vierge, sans extension) est présent et en fonction on va ajouter le bon fichier de configuration.
Si aucun fichier de configuration existe il faut tout arrêter, car sans fichier de configuration, il est impossible de continuer donc c’est très important !

Le fichier de production pourrait contenir les informations de connexion à la base de données ainsi que les éléments pour cacher les erreurs, mais les sauvegarder dans un fichier.

define('WP_ROOT', dirname(__FILE__));

@ini_set('display_errors', 0);
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);

if (!is_dir(WP_ROOT . '/logs/')) {
    mkdir(WP_ROOT . '/logs/');
}
@ini_set('log_errors', 1);
@ini_set('error_log', WP_ROOT . '/logs/debug.log');

Dans un premier temps, on crée une constante pour avoir facilement la racine du WordPress.

Ensuite, on cache les erreurs au niveau de php.ini (init_set) mais aussi dans WordPress grâce aux différentes constantes.

On continue en créant un dossier pour stocker les erreurs.

Et on termine en autorisant le stockage des erreurs (log_errors) et en précisant le fichier de debug (debug.log).

Le @ est important car il permet de cacher une erreur. Dans notre cas, une erreur pourrait survenir si par exemple display_errors était déjà défini, en ajoutant le @ on n’affichera pas d’erreur (même principe pour les autres @ de l’exemple).

Cette méthode vous donne une base pour configurer un environnement spécifique en fonction de vos développements. Elle est à adapter en fonction de vos besoins et sûrement à améliorer 😀