wp-config.php : les réglages utiles que peu de gens activent

Le fichier wp-config.php concentre des réglages que la plupart des administrateurs WordPress ignorent

À la une

Le fichier wp-config.php contient bien plus que les identifiants de base de données : une dizaine de constantes permettent de limiter les révisions, forcer le HTTPS, désactiver l’éditeur de fichiers ou vider automatiquement la corbeille, sans installer le moindre plugin. La plupart des installations WordPress n’exploitent pourtant qu’une fraction de ces réglages, faute de savoir qu’ils existent ou par crainte de casser quelque chose.

Ce guide détaille chaque paramètre utile, explique sa syntaxe exacte et précise dans quel ordre l’insérer pour éviter les conflits. Avant toute modification, il est recommandé de travailler sur un environnement de préproduction et de disposer d’une sauvegarde récente.

Dans cet article

Le fichier wp-config.php accepte plus de 30 constantes documentées par WordPress.org, mais la majorité des sites n’en utilisent que 5 ou 6
Limiter les révisions avec WP_POST_REVISIONS réduit significativement le volume de la base de données
Forcer le SSL côté administration se fait en une seule ligne sans extension
Le mode WP_DEBUG_LOG enregistre les erreurs dans un fichier sans les afficher aux visiteurs
Désactiver l’éditeur de fichiers intégré (DISALLOW_FILE_EDIT) ferme un vecteur d’attaque courant
Toutes les constantes doivent être placées avant la ligne « That’s all » pour être prises en compte

Sommaire

wp-config.php : ce que contient réellement ce fichier
Avant la ligne « That’s all » : où insérer chaque constante
WP_DEBUG et WP_DEBUG_LOG : traquer les erreurs sans affoler les visiteurs
Révisions et corbeille : deux constantes qui allègent la base de données
Sécurité : désactiver l’éditeur de fichiers et forcer le HTTPS
Mémoire PHP, CRON alternatif et concaténation des scripts
Mises à jour automatiques : contrôler ce qui se met à jour tout seul
Tableau récapitulatif des constantes les plus utiles
Les erreurs fréquentes qui cassent le site après modification

wp-config.php : ce que contient réellement ce fichier

Le fichier wp-config.php est le premier fichier chargé par WordPress à chaque requête. Il définit les paramètres de connexion à la base de données (nom, utilisateur, mot de passe, hôte), les clés de salage qui sécurisent les cookies d’authentification, le préfixe des tables et la langue du site. Selon la documentation officielle WordPress, ce fichier accepte plusieurs dizaines de constantes PHP facultatives qui modifient le comportement du CMS sans toucher au code source ni installer d’extension.

Contrairement aux réglages accessibles depuis le tableau de bord, les constantes inscrites dans wp-config.php priment sur la base de données. Si une option est définie à la fois dans wp_options et dans wp-config.php, c’est la valeur du fichier qui l’emporte. Ce mécanisme est utile pour verrouiller un paramètre et empêcher qu’un utilisateur administrateur ne le modifie accidentellement depuis l’interface.

Le fichier se trouve à la racine de l’installation WordPress, au même niveau que les dossiers wp-admin, wp-content et wp-includes. Il est généré automatiquement lors de l’installation, à partir du modèle wp-config-sample.php fourni dans l’archive. Sur certains hébergeurs, il peut être déplacé un niveau au-dessus de la racine publique pour renforcer la sécurité : WordPress le détecte automatiquement à cet emplacement.

Avant la ligne « That’s all » : où insérer chaque constante

Toute constante ajoutée dans wp-config.php doit être placée avant le commentaire /* That's all, stop editing! Happy publishing. */. Les lignes situées après ce commentaire déclenchent le chargement du noyau WordPress via wp-settings.php : une constante définie trop bas serait tout simplement ignorée.

L’ordre recommandé est le suivant :

Identifiants de base de données (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST)
Préfixe de table ($table_prefix)
Clés de salage (AUTH_KEY, SECURE_AUTH_KEY, etc.)
Constantes personnalisées (debug, révisions, sécurité, mises à jour)
Commentaire « That’s all »
Chargement de wp-settings.php

En pratique, il suffit d’ouvrir le fichier avec un éditeur de texte brut (pas un traitement de texte) et d’ajouter les lignes souhaitées juste au-dessus du commentaire final. L’utilisation d’un outil de versionnement comme Git permet de revenir en arrière en cas d’erreur de syntaxe.

Voir aussi Combien de plugins c’est trop ? La vraie question n’est pas le nombre

WP_DEBUG et WP_DEBUG_LOG : traquer les erreurs sans affoler les visiteurs

Le mode débogage de WordPress s’active avec trois constantes complémentaires. Ensemble, elles enregistrent toutes les erreurs PHP et les avertissements WordPress dans un fichier journal, sans afficher le moindre message à l’écran :

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

Avec cette configuration, les erreurs sont consignées dans le fichier wp-content/debug.log. Ce fichier est accessible par FTP ou via le gestionnaire de fichiers de l’hébergeur. Il révèle les fonctions dépréciées, les notices PHP, les conflits entre extensions et les appels à des fichiers inexistants.

Sur un site en production, WP_DEBUG doit rester sur false une fois le diagnostic terminé. Laisser le débogage actif en permanence ralentit marginalement le site et fait grossir le fichier de log. Pour une utilisation ponctuelle, il est préférable de diagnostiquer sur un environnement de staging, puis de désactiver le mode debug une fois le problème résolu.

La constante SCRIPT_DEBUG, moins connue, force WordPress à charger les versions non minifiées des fichiers CSS et JavaScript du noyau. Elle est utile aux développeurs qui travaillent sur un thème enfant et souhaitent identifier une règle CSS spécifique dans les fichiers sources :

define( 'SCRIPT_DEBUG', true );

Révisions et corbeille : deux constantes qui allègent la base de données

Par défaut, WordPress enregistre un nombre illimité de révisions pour chaque article ou page. Sur un site actif depuis plusieurs années, la table wp_posts peut contenir des dizaines de milliers de lignes de révisions qui alourdissent la base de données et ralentissent les requêtes. La constante WP_POST_REVISIONS permet de fixer une limite :

define( 'WP_POST_REVISIONS', 5 );

Avec cette valeur, WordPress conserve uniquement les cinq dernières révisions de chaque contenu. Les révisions excédentaires ne sont pas supprimées rétroactivement : il faut passer par un nettoyage de la base de données pour éliminer les anciennes entrées. La valeur false désactive complètement les révisions, tandis que true rétablit le comportement illimité par défaut.

La corbeille de WordPress conserve les contenus supprimés pendant 30 jours avant de les effacer définitivement. Ce délai se modifie avec EMPTY_TRASH_DAYS :

define( 'EMPTY_TRASH_DAYS', 7 );

La valeur 0 supprime la corbeille : tout contenu effacé disparaît immédiatement et de façon irréversible. Ce réglage est à réserver aux sites où la suppression accidentelle est peu probable et où la base de données doit rester aussi légère que possible.

L’intervalle d’enregistrement automatique des brouillons se règle également depuis wp-config.php. Par défaut fixé à 60 secondes, il peut être allongé pour réduire les requêtes AJAX sur les serveurs partagés :

define( 'AUTOSAVE_INTERVAL', 120 );

Sécurité : désactiver l’éditeur de fichiers et forcer le HTTPS

WordPress embarque un éditeur de thèmes et d’extensions accessible depuis le menu Apparence puis Éditeur de fichiers du thème. Cet outil permet de modifier directement le code PHP des fichiers depuis le navigateur. En cas de piratage du compte administrateur, l’attaquant peut injecter du code malveillant en quelques secondes. La constante suivante supprime complètement cet éditeur :

define( 'DISALLOW_FILE_EDIT', true );

Une variante plus restrictive, DISALLOW_FILE_MODS, interdit en plus toute installation ou mise à jour d’extensions et de thèmes depuis le tableau de bord. Elle est utilisée dans les environnements gérés par déploiement automatisé, où chaque modification passe par un processus de versionnement :

define( 'DISALLOW_FILE_MODS', true );

Pour forcer l’utilisation du protocole HTTPS sur l’ensemble de l’administration, deux constantes entrent en jeu. Elles sont utiles lorsque le certificat SSL est déjà installé mais que certaines pages d’administration chargent encore en HTTP, provoquant des erreurs de contenu mixte :

define( 'FORCE_SSL_ADMIN', true );

Cette constante redirige automatiquement toutes les requêtes vers wp-admin et wp-login.php en HTTPS. Selon la documentation WordPress sur le SSL, elle remplace l’ancienne constante FORCE_SSL_LOGIN qui ne couvrait que la page de connexion.

Côté connexion, un plugin de sécurité complète utilement ces constantes en ajoutant la double authentification et le blocage des attaques par force brute.

Mémoire PHP, CRON alternatif et concaténation des scripts

La limite de mémoire PHP allouée à WordPress est fixée par défaut à 40 Mo pour le front-end et à 256 Mo pour l’administration. Si une extension gourmande provoque une erreur « Allowed memory size exhausted », la constante WP_MEMORY_LIMIT permet d’augmenter ce plafond :

define( 'WP_MEMORY_LIMIT', '128M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

WP_MAX_MEMORY_LIMIT concerne spécifiquement le tableau de bord. Ces valeurs ne peuvent pas dépasser la limite fixée par l’hébergeur dans la configuration PHP du serveur. Si le fichier php.ini autorise 128 Mo, définir 256 Mo dans wp-config.php n’aura aucun effet.

Le système de tâches planifiées de WordPress, WP-Cron, fonctionne différemment d’un vrai CRON système. Il se déclenche à chaque visite d’un internaute, ce qui pose deux problèmes : sur un site à faible trafic, les tâches s’exécutent en retard ; sur un site à fort trafic, elles se déclenchent trop souvent. La solution consiste à désactiver WP-Cron et à le remplacer par une tâche CRON système :

define( 'DISABLE_WP_CRON', true );

Une fois cette constante activée, il faut configurer un CRON côté serveur (via cPanel, Plesk ou la ligne de commande) pour appeler wp-cron.php toutes les 5 à 15 minutes. Cette méthode garantit une exécution régulière des mises à jour automatiques, des publications programmées et des sauvegardes planifiées.

Sur les hébergements mutualisés où le tableau de bord est lent, la constante CONCATENATE_SCRIPTS peut améliorer les temps de chargement de l’administration en regroupant les fichiers JavaScript du noyau en une seule requête :

define( 'CONCATENATE_SCRIPTS', true );

Ce réglage est activé par défaut sur la plupart des installations, mais certains hébergeurs ou extensions de cache le désactivent. La minification CSS et JS côté front-end reste complémentaire et ne remplace pas cette concaténation interne.

Mises à jour automatiques : contrôler ce qui se met à jour tout seul

Depuis WordPress 5.6, les mises à jour automatiques du noyau sont activées par défaut pour les versions mineures (correctifs de sécurité). Plusieurs constantes permettent d’affiner ce comportement directement dans wp-config.php :

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Les trois valeurs possibles sont true (toutes les mises à jour, y compris majeures), 'minor' (uniquement les correctifs) et false (aucune mise à jour automatique). La valeur 'minor' est le choix le plus équilibré selon la documentation WordPress francophone : elle applique les correctifs de sécurité sans risquer une rupture de compatibilité liée à une montée de version majeure.

Pour désactiver complètement toute mise à jour automatique, y compris celles des extensions et des thèmes :

define( 'AUTOMATIC_UPDATER_DISABLED', true );

Cette constante est à utiliser avec prudence. Un site dont les extensions ne sont jamais mises à jour accumule des failles de sécurité. Le choix de désactiver les mises à jour automatiques implique de mettre en place un processus manuel régulier, idéalement via un environnement de staging.

Le nombre d’extensions installées influe aussi sur la charge de mise à jour. L’article sur le nombre optimal de plugins permet de faire le tri avant de décider quoi automatiser.

Tableau récapitulatif des constantes les plus utiles

Le tableau ci-dessous regroupe les constantes abordées dans cet article, avec leur valeur recommandée et leur effet principal :

Constante	Valeur recommandée	Effet
WP_DEBUG	false (production)	Active ou désactive le mode débogage
WP_DEBUG_LOG	true (en staging)	Enregistre les erreurs dans debug.log
WP_DEBUG_DISPLAY	false	Masque les erreurs à l’écran
SCRIPT_DEBUG	false (production)	Charge les fichiers JS/CSS non minifiés
WP_POST_REVISIONS	5	Limite le nombre de révisions par contenu
EMPTY_TRASH_DAYS	7	Vide la corbeille après 7 jours
AUTOSAVE_INTERVAL	120	Enregistrement automatique toutes les 2 min
DISALLOW_FILE_EDIT	true	Supprime l’éditeur de fichiers intégré
DISALLOW_FILE_MODS	true (env. géré)	Bloque installation et mises à jour depuis le back-office
FORCE_SSL_ADMIN	true	Force le HTTPS sur l’administration
WP_MEMORY_LIMIT	‘128M’	Augmente la mémoire PHP pour le front-end
WP_MAX_MEMORY_LIMIT	‘512M’	Augmente la mémoire PHP pour l’administration
DISABLE_WP_CRON	true	Désactive WP-Cron au profit d’un CRON système
WP_AUTO_UPDATE_CORE	‘minor’	Mises à jour automatiques limitées aux correctifs
AUTOMATIC_UPDATER_DISABLED	false	Maintient les mises à jour automatiques actives

Les erreurs fréquentes qui cassent le site après modification

La première cause de panne après édition de wp-config.php est une erreur de syntaxe PHP. Un guillemet manquant, un point-virgule oublié ou un caractère invisible copié depuis un traitement de texte suffit à provoquer un écran blanc. Le fichier doit être édité avec un éditeur de code (VS Code, Sublime Text, Notepad++) et jamais avec Word ou Google Docs.

L’utilisation de guillemets typographiques (« » ou

Damien Roux

Damien Roux est spécialiste de l'hébergement web. Fondateur de web-city.fr, il partage guides pratiques, comparatifs objectifs et outils gratuits pour choisir le bon hébergeur et créer son site WordPress.