wp-config.php : 15 constantes clés à bien régler

by | WordPress

Si vous avez déjà vu un “Error establishing a database connection” à 2h du matin ou un écran blanc après avoir “juste ajouté une constante”, vous savez que wp-config.php n’est pas un fichier où l’on improvise.

Sur WordPress 6.9.4 (avril 2026) et PHP 8.1+, wp-config.php reste le point d’entrée des réglages serveur les plus sensibles : base de données, clés de sécurité, debug, HTTPS derrière proxy, cron, limites mémoire. Bien configuré, il stabilise un site. Mal modifié, il le met hors ligne.

Le besoin / Le problème serveur

Vous voulez un WordPress qui se connecte correctement à sa base, qui loggue les erreurs sans les afficher aux visiteurs, qui ne se déconnecte pas au hasard, et qui ne “casse” pas dès que vous passez derrière Cloudflare, un reverse proxy Nginx, ou un hébergeur un peu strict.

À la fin, vous saurez :

  • identifier et modifier wp-config.php au bon endroit (et au bon moment dans le fichier) ;
  • configurer 15 constantes essentielles, avec une logique serveur (prod vs staging) ;
  • tester vos changements via SSH, WP-CLI, MySQL et curl ;
  • revenir en arrière vite si vous faites une erreur (ça arrive, même aux pros).

Résumé rapide

  • Ne modifiez jamais le core : uniquement wp-config.php et vos fichiers serveur.
  • Les 4 constantes “base de données” à vérifier en premier : DB_NAME, DB_USER, DB_PASSWORD, DB_HOST.
  • Les 8 clés/salts se rotatent en cas de doute : cela déconnecte tout le monde (normal).
  • Sur serveur, activez un debug qui écrit dans un log : WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY.
  • Derrière proxy/SSL (Cloudflare, Nginx, load balancer), FORCE_SSL_ADMIN et $_SERVER['HTTPS'] (avec précaution) évitent les boucles et mixed content.
  • Pour calmer les sites “lents” : WP_POST_REVISIONS, DISABLE_WP_CRON + cron système, WP_MEMORY_LIMIT.

Avant de commencer (prérequis)

Vous allez toucher à un fichier chargé à chaque requête. Une erreur de point-virgule peut mettre le site en erreur 500. Je le vois souvent sur des sites où un snippet a été collé après la ligne “stop editing”.

Accès nécessaires

  • SSH (recommandé) pour éditer et tester rapidement.
  • FTP/SFTP si vous n’avez pas SSH (moins pratique mais possible).
  • Accès MySQL (CLI ou phpMyAdmin) pour vérifier les identifiants.
  • WP-CLI (fortement recommandé) pour diagnostiquer sans passer par l’admin.

Sauvegarde obligatoire (fichiers + base)

Avant toute modification, faites une sauvegarde copiable et restaurable. Voici des commandes typiques via SSH. La première sauvegarde wp-config.php, la seconde exporte la base via WP-CLI (si disponible).

# Sauvegarde du fichier wp-config.php (dans le même dossier)
cp -a wp-config.php wp-config.php.bak.$(date +%F-%H%M)

# Export SQL via WP-CLI (à exécuter à la racine WordPress)
wp db export ~/backup-$(date +%F-%H%M).sql

Versions serveur recommandées (avril 2026)

  • WordPress : 6.9.4
  • PHP : 8.1+ (8.2/8.3 très courant en prod)
  • MySQL : 8.0+ ou MariaDB 10.6+
  • Serveur web : Nginx ou Apache (les deux conviennent)

Pour vérifier rapidement vos versions :

php -v
mysql --version
wp --info

Étape 1 : Localiser, lire et sécuriser wp-config.php sans casser le site

Où se trouve wp-config.php

Dans 95% des cas, wp-config.php est à la racine de l’installation WordPress (là où se trouvent wp-settings.php et wp-content/). Parfois, il est déplacé un niveau au-dessus (mesure de sécurité classique) : WordPress le supporte.

Depuis la racine web :

# Liste les fichiers "sensibles" à la racine
ls -la

# Cherche wp-config.php dans le dossier courant et le parent
find .. -maxdepth 2 -name wp-config.php -type f -print

Permissions : éviter l’exposition accidentelle

Sur un serveur Linux standard, wp-config.php doit être lisible par l’utilisateur du serveur web, mais pas “ouvert à tous”. J’ai souvent vu du 777 “pour que ça marche” : c’est une porte ouverte.

# Exemple raisonnable si votre utilisateur Unix possède le fichier
chmod 640 wp-config.php

# Vérifier propriétaire/groupe
ls -l wp-config.php

Si vous êtes sur un hébergement mutualisé, votre contexte peut imposer autre chose. Le principe reste : le minimum de droits.

Règle d’or : placer les constantes avant “stop editing”

Dans wp-config.php, cherchez cette ligne :

/* C'est tout, ne touchez pas à ce qui suit ! Bon blogging ! */

Tout ce que vous ajoutez doit être au-dessus. En dessous, WordPress charge ses fichiers et vos constantes risquent d’être ignorées ou de déclencher des comportements bizarres.

Étape 2 : Base de données et encodage (4 constantes à valider)

Quand la base de données est mal configurée, le site ne démarre pas. C’est la première zone à contrôler lors d’une migration, d’un staging, ou d’un changement d’hébergeur.

1) DB_NAME

Nom de la base. Sur certains hébergeurs, il est préfixé (ex: u12345_wp).

2) DB_USER

Utilisateur MySQL. Évitez d’utiliser un compte “root”. Créez un utilisateur dédié avec droits limités sur cette base.

3) DB_PASSWORD

Mot de passe MySQL. S’il contient des caractères spéciaux, pas de problème en PHP tant que c’est entre guillemets et que vous ne cassez pas la chaîne.

4) DB_HOST

Souvent localhost. Parfois un hostname (ex: db01.internal) ou un port (ex: 127.0.0.1:3306). Certains hébergeurs imposent un socket, mais c’est plus rare côté WordPress.

Exemple typique dans wp-config.php :

<?php
// ... début du fichier

/** Nom de la base de données WordPress */
define( 'DB_NAME', 'wordpress' );

/** Identifiant de base de données */
define( 'DB_USER', 'wp_user' );

/** Mot de passe de base de données */
define( 'DB_PASSWORD', 'mot-de-passe-super-long' );

/** Adresse de l’hôte MySQL */
define( 'DB_HOST', 'localhost' );

Test serveur : valider la connexion MySQL sans WordPress

Avant d’accuser WordPress, testez la connexion MySQL avec les mêmes identifiants. Cette commande vous dit tout de suite si le problème est “réseau/identifiants” ou “WordPress”.

# Remplacez user, host et nom de base
mysql -u wp_user -p -h localhost wordpress -e "SELECT 1;"

Encodage : DB_CHARSET et DB_COLLATE (à vérifier, pas à bricoler)

Je ne compte plus les migrations où des caractères accentués se transforment en losanges. Sur WordPress moderne, utf8mb4 est la valeur attendue. En pratique, vous laissez souvent les valeurs par défaut du générateur WordPress, sauf cas legacy.

/** Encodage de la base de données à utiliser lors de la création des tables. */
define( 'DB_CHARSET', 'utf8mb4' );

/** Type de collation de la base de données. Ne modifiez pas si vous ne savez pas. */
define( 'DB_COLLATE', '' );

Si vous migrez un vieux site (avant l’adoption large de utf8mb4), traitez ça comme une migration de charset côté MySQL, pas juste un changement de constante. Référence utile : developer.wordpress.org – Database character sets.

Étape 3 : Clés de sécurité (AUTH_KEY… SALT) et rotation propre

Les clés et “salts” signent vos cookies de connexion. Si elles fuient (backup exposé, repo Git public, accès FTP compromis), un attaquant peut fabriquer des cookies valides. La rotation coupe court, au prix d’une déconnexion générale.

Les 8 constantes à connaître (elles comptent comme 8 des 15 essentielles) :

  • AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY
  • AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, NONCE_SALT

Générez-les via le service officiel WordPress :

api.wordpress.org – Secret Key Service

Exemple (valeurs raccourcies ici, remplacez par les vôtres complètes) :

/**#@+
 * Clés uniques d'authentification et salage.
 * Changez-les pour invalider toutes les sessions (déconnexion générale).
 */
define( 'AUTH_KEY',         'mettez-ici-une-chaine-longue-et-aleatoire' );
define( 'SECURE_AUTH_KEY',  'mettez-ici-une-chaine-longue-et-aleatoire' );
define( 'LOGGED_IN_KEY',    'mettez-ici-une-chaine-longue-et-aleatoire' );
define( 'NONCE_KEY',        'mettez-ici-une-chaine-longue-et-aleatoire' );
define( 'AUTH_SALT',        'mettez-ici-une-chaine-longue-et-aleatoire' );
define( 'SECURE_AUTH_SALT', 'mettez-ici-une-chaine-longue-et-aleatoire' );
define( 'LOGGED_IN_SALT',   'mettez-ici-une-chaine-longue-et-aleatoire' );
define( 'NONCE_SALT',       'mettez-ici-une-chaine-longue-et-aleatoire' );
/**#@-*/

Observation terrain : “je suis déconnecté tout le temps”

Quand je vois des déconnexions aléatoires, la cause est souvent ailleurs (cache agressif, proxy mal configuré, cookies bloqués), mais j’ai déjà croisé des cas où les clés étaient différentes entre deux serveurs derrière un load balancer. Résultat : une requête sur deux invalide la session. Si vous avez plusieurs web servers, le même wp-config.php (ou au moins les mêmes clés) doit être déployé partout.

Étape 4 : Debug “raisonnable” sur serveur (3 constantes + 1 extra utile)

Le debug est indispensable… à condition de ne pas afficher des erreurs PHP aux visiteurs. Sur un site public, afficher les erreurs peut exposer des chemins serveur, des versions, voire des données.

12) WP_DEBUG

Active le mode debug WordPress (affichage/collecte des notices selon les autres constantes).

13) WP_DEBUG_LOG

Écrit les erreurs dans un fichier log. Sur WordPress actuel, vous pouvez mettre true (log par défaut) ou un chemin. En production, je préfère un chemin explicite hors webroot quand c’est possible.

14) WP_DEBUG_DISPLAY

Contrôle l’affichage à l’écran. En prod : false.

Extra utile : SCRIPT_DEBUG

Ce n’est pas dans les “15” de base, mais je l’active souvent en staging quand un builder (Divi 5 / Elementor / Avada) a un souci de JS/CSS minifié. Ça force WordPress à charger des versions non minifiées de certains assets core, ce qui aide à diagnostiquer.

// Debug serveur : log oui, affichage non (recommandé en production)
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true ); // Écrit dans wp-content/debug.log par défaut
define( 'WP_DEBUG_DISPLAY', false );

// Aide au diagnostic JS/CSS (plutôt en staging)
define( 'SCRIPT_DEBUG', false );

Si vous activez le log, vérifiez que le fichier n’est pas exposé publiquement. Sur certains serveurs, wp-content/debug.log peut être téléchargeable si mal configuré.

Référence officielle : developer.wordpress.org – Debug WordPress.

Étape 5 : HTTPS, reverse proxy et administration (2 constantes)

Si vous êtes derrière Cloudflare, un reverse proxy Nginx, ou un load balancer, WordPress peut “croire” qu’il est en HTTP alors que le visiteur est en HTTPS. Symptômes typiques : boucles de redirection, cookies “Secure” mal posés, admin qui saute en HTTP.

15) FORCE_SSL_ADMIN

Force l’administration en HTTPS. Utile quand votre front est bien en HTTPS mais que l’admin se comporte mal.

// Force HTTPS dans /wp-admin (utile derrière certains proxies)
define( 'FORCE_SSL_ADMIN', true );

16) (Constante essentielle côté proxy) : WP_HOME / WP_SITEURL ?

Je ne les compte pas dans les “15” que je recommande à tous, parce qu’elles figent les URLs (ce qui peut gêner un staging). Mais sur serveur, elles résolvent vite les migrations incomplètes et les boucles de redirection. Si votre site redirige vers un ancien domaine, c’est souvent la solution la plus rapide.

Vous pouvez choisir de les utiliser à la place d’une autre constante si votre cas l’exige. Exemple :

// Fige les URLs (pratique après migration, attention en staging)
define( 'WP_HOME', 'https://exemple.com' );
define( 'WP_SITEURL', 'https://exemple.com' );

Référence : developer.wordpress.org – WP_HOME / WP_SITEURL.

Cas reverse proxy : forcer HTTPS via $_SERVER (avec prudence)

Ce n’est pas une constante, mais c’est un correctif serveur fréquent. Si votre proxy termine le SSL et parle en HTTP à PHP-FPM, vous devez vous appuyer sur un header fiable (X-Forwarded-Proto) uniquement si vous contrôlez le proxy. Sinon, un client peut forger le header.

// Reverse proxy : WordPress doit "voir" HTTPS.
// À n'utiliser que si votre proxy ajoute X-Forwarded-Proto de manière fiable.
if ( ! empty( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
	$_SERVER['HTTPS'] = 'on';
}

Étape 6 : Révisions, Cron et mémoire PHP (3 constantes)

Ici, on vise des gains concrets : moins de bloat en base, un cron stable, et moins d’erreurs “Allowed memory size exhausted”. Je croise ces problèmes très souvent sur des sites avec Elementor, Divi 5 ou Avada, parce que les pages sont plus lourdes et les opérations (imports, optimisations d’images, indexations) consomment plus.

11) WP_POST_REVISIONS

Contrôle le nombre de révisions d’articles conservées. Sur des blogs actifs, limiter les révisions évite que la table wp_posts gonfle inutilement.

// Limite les révisions par contenu (0 = désactive, ce que je déconseille souvent)
define( 'WP_POST_REVISIONS', 10 );

10) DISABLE_WP_CRON

WordPress lance des tâches planifiées via des visites (pseudo-cron). Sur un site à trafic faible, les tâches ne partent pas. Sur un site à fort trafic, ça peut déclencher trop souvent. En serveur, la solution propre est : désactiver WP-Cron et le remplacer par un cron système.

// Désactive WP-Cron (vous devez configurer un cron système à la place)
define( 'DISABLE_WP_CRON', true );

Ensuite, créez un cron Linux (toutes les 5 minutes est un bon départ). Cette commande appelle wp-cron.php sans dépendre des visites. Je préfère curl en mode silencieux.

# Éditez la crontab de l'utilisateur qui a le droit d'appeler le site
crontab -e
*/5 * * * * curl -sS https://exemple.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Référence : developer.wordpress.org – WP-Cron.

9) WP_MEMORY_LIMIT

Augmente la limite mémoire PHP demandée par WordPress. Attention : ça ne dépasse pas la limite réelle imposée par PHP (memory_limit) ou par l’hébergeur. Mais ça évite des situations où PHP autorise 512M, tandis que WordPress se limite à 40M/64M selon contexte.

// Mémoire demandée par WordPress (doit rester cohérente avec php.ini)
define( 'WP_MEMORY_LIMIT', '256M' );

Référence : developer.wordpress.org – WP_MEMORY_LIMIT.

Récapitulatif des 15 constantes “essentielles” retenues ici (celles que je recommande de connaître et savoir configurer sur WordPress 6.9.4) :

  • Base de données (4) : DB_NAME, DB_USER, DB_PASSWORD, DB_HOST
  • Charset/collation (2) : DB_CHARSET, DB_COLLATE
  • Clés/salts (8) : AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, NONCE_SALT
  • Serveur/HTTPS (1) : FORCE_SSL_ADMIN

Et, selon votre contexte, j’ajoute très souvent WP_DEBUG/WP_DEBUG_LOG/WP_DEBUG_DISPLAY, DISABLE_WP_CRON et WP_MEMORY_LIMIT (elles sont “essentielles” en exploitation), même si ça dépasse le strict décompte. Sur le terrain, ce sont celles qui vous évitent le plus de pannes et de pertes de temps.

Fichiers de configuration complets

Cette section est volontairement “prête à copier-coller”, mais vous devez adapter domaines, chemins et identifiants. Ne copiez jamais des clés/salts depuis un tuto : générez-les.

wp-config.php (exemple complet WordPress 6.9.4 / PHP 8.1+)

<?php
/**
 * Configuration de base WordPress.
 * WordPress 6.9.4+ / PHP 8.1+
 *
 * Astuce : placez ce fichier un niveau au-dessus du webroot si votre hébergeur le permet.
 */

// --- Base de données ---
define( 'DB_NAME', 'wordpress' );
define( 'DB_USER', 'wp_user' );
define( 'DB_PASSWORD', 'mot-de-passe-super-long' );
define( 'DB_HOST', 'localhost' );

define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

// --- Clés de sécurité (remplacez par celles générées via api.wordpress.org) ---
define( 'AUTH_KEY',         'remplacez-par-une-chaine-longue-et-aleatoire' );
define( 'SECURE_AUTH_KEY',  'remplacez-par-une-chaine-longue-et-aleatoire' );
define( 'LOGGED_IN_KEY',    'remplacez-par-une-chaine-longue-et-aleatoire' );
define( 'NONCE_KEY',        'remplacez-par-une-chaine-longue-et-aleatoire' );
define( 'AUTH_SALT',        'remplacez-par-une-chaine-longue-et-aleatoire' );
define( 'SECURE_AUTH_SALT', 'remplacez-par-une-chaine-longue-et-aleatoire' );
define( 'LOGGED_IN_SALT',   'remplacez-par-une-chaine-longue-et-aleatoire' );
define( 'NONCE_SALT',       'remplacez-par-une-chaine-longue-et-aleatoire' );

// --- HTTPS / Admin ---
define( 'FORCE_SSL_ADMIN', true );

// Reverse proxy : à activer seulement si votre infra ajoute un X-Forwarded-Proto fiable.
if ( ! empty( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
	$_SERVER['HTTPS'] = 'on';
}

// --- Exploitation (optionnel mais très utile) ---
// Debug : log oui, affichage non (production)
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

// Révisions : limite pour éviter le gonflement de la base
define( 'WP_POST_REVISIONS', 10 );

// Cron : préférez un cron système si DISABLE_WP_CRON = true
define( 'DISABLE_WP_CRON', true );

// Mémoire : doit rester cohérent avec le memory_limit PHP
define( 'WP_MEMORY_LIMIT', '256M' );

// --- Chemin absolu WordPress ---
if ( ! defined( 'ABSPATH' ) ) {
	define( 'ABSPATH', __DIR__ . '/' );
}

// --- Démarrage WordPress ---
require_once ABSPATH . 'wp-settings.php';

.htaccess (Apache) : règles de base + protection debug.log

Si vous êtes sur Apache, voici un .htaccess classique. J’ajoute une protection simple pour empêcher le téléchargement de debug.log (utile si vous activez WP_DEBUG_LOG).

# Fichier .htaccess (Apache)
# Attention : adapté pour WordPress, à placer à la racine web

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

# Bloque l'accès direct au debug.log si présent
<Files "debug.log">
Require all denied
</Files>

nginx.conf (server block) : WordPress + blocage debug.log

Sur Nginx, vous ne devez pas utiliser .htaccess. Voici un exemple minimaliste (à adapter). Le bloc location sur debug.log évite une fuite de logs.

# Extrait Nginx (server block)
server {
    listen 80;
    server_name exemple.com;
    root /var/www/exemple.com/public;

    index index.php index.html;

    # Bloque un fichier de log potentiel
    location = /wp-content/debug.log {
        deny all;
    }

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ .php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }

    location ~* .(js|css|png|jpg|jpeg|gif|svg|webp|ico)$ {
        expires 30d;
        add_header Cache-Control "public, max-age=2592000";
    }
}

php.ini (ou override) : mémoire et logs PHP

Selon votre hébergeur, vous modifierez php.ini, un pool PHP-FPM, ou un fichier .user.ini. L’objectif : aligner memory_limit avec WP_MEMORY_LIMIT et activer un log PHP côté serveur (distinct de WordPress).

; Exemple php.ini / override
memory_limit = 512M
log_errors = On
error_log = /var/log/php/php-error.log
display_errors = Off

Référence PHP officielle : php.net – error handling configuration.

Vérification

Après modification, ne vous contentez pas de “rafraîchir le site”. Validez par étapes : syntaxe PHP, accès base, état WordPress, HTTPS, cron.

1) Vérifier la syntaxe PHP de wp-config.php

Cette commande détecte immédiatement un point-virgule manquant ou une parenthèse oubliée.

php -l wp-config.php

2) Vérifier que WordPress répond (HTTP)

Test rapide de la page d’accueil :

curl -I https://exemple.com/

3) Vérifier l’accès base via WP-CLI

Si WP-CLI fonctionne, c’est un excellent signal que wp-config.php est cohérent.

# À la racine WordPress
wp core version
wp db check

4) Vérifier le cron (si DISABLE_WP_CRON=true)

Si vous avez mis en place un cron système, vous pouvez déclencher manuellement :

curl -sS https://exemple.com/wp-cron.php?doing_wp_cron >/dev/null

5) Vérifier le log WordPress (si WP_DEBUG_LOG=true)

Vérifiez la présence et les droits. Sur un site actif, il peut être créé à la première erreur seulement.

ls -la wp-content/debug.log
tail -n 50 wp-content/debug.log

Si ça ne marche pas

Quand le site tombe après modification de wp-config.php, le problème vient presque toujours d’une de ces causes : syntaxe PHP, constante redéfinie, fichier édité au mauvais endroit, ou cache/proxy qui masque le vrai état.

Diagnostic par étapes (rapide et fiable)

  1. Revenez au backup : remettez wp-config.php.bak... si nécessaire.
  2. Testez la syntaxe : php -l wp-config.php.
  3. Regardez les logs serveur (Nginx/Apache + PHP-FPM) : c’est là que l’erreur 500 est expliquée.
  4. Vérifiez DB_HOST : confusion classique entre localhost et un hostname interne.
  5. Si reverse proxy : vérifiez les headers X-Forwarded-Proto et les boucles 301/302.

Où lire les logs (exemples)

# Nginx
sudo tail -n 200 /var/log/nginx/error.log

# Apache (chemin variable selon distro)
sudo tail -n 200 /var/log/apache2/error.log

# PHP-FPM (chemin variable)
sudo tail -n 200 /var/log/php8.2-fpm.log

Tableau de diagnostic (symptôme → cause → vérification → solution)

Symptôme Cause probable Vérification Solution
Erreur 500 juste après modification Syntaxe PHP cassée (point-virgule, guillemet) php -l wp-config.php + logs PHP-FPM Corriger la ligne, restaurer le backup si besoin
“Error establishing a database connection” Identifiants DB incorrects / host incorrect mysql -u ... -p -h ... Corriger DB_*, vérifier droits MySQL
Boucle de redirection http↔https Proxy SSL mal interprété curl -I (codes 301/302 en boucle), headers Configurer le proxy, ajuster $_SERVER['HTTPS'] avec prudence, vérifier WP_HOME/WP_SITEURL
Admin qui repasse en HTTP FORCE_SSL_ADMIN absent + SSL terminé ailleurs Tester /wp-admin/ avec curl -I Activer FORCE_SSL_ADMIN, corriger la détection HTTPS
Tâches planifiées qui ne partent plus DISABLE_WP_CRON activé sans cron système Vérifier crontab -l, tester wp-cron.php Ajouter un cron Linux ou réactiver WP-Cron
“Allowed memory size exhausted” Limite PHP trop basse Logs PHP + php -i | grep memory_limit Augmenter memory_limit et WP_MEMORY_LIMIT

Pièges et erreurs courantes

Erreur Cause Solution
Constante ajoutée sous “stop editing” WordPress a déjà chargé sa config Remonter la constante au-dessus du commentaire de fin
Copier le code dans le mauvais fichier Édition de wp-settings.php ou d’un fichier de thème Ne jamais modifier le core. Uniquement wp-config.php
Oubli d’un point-virgule Erreur de syntaxe PHP php -l wp-config.php avant de tester dans le navigateur
Clés/salts différentes entre deux serveurs Déploiement incohérent en multi-serveur Synchroniser wp-config.php (ou au moins les clés) sur tous les nœuds
Activer WP_DEBUG_DISPLAY en production Erreurs visibles par les visiteurs WP_DEBUG_DISPLAY à false + logs serveur
Conflit avec cache/proxy Cloudflare/Varnish sert une ancienne redirection Purger le cache proxy + navigateur, re-tester avec curl Purge + vérifier headers
Tester en production sans sauvegarde Restauration impossible en cas d’erreur Backup fichier + DB avant chaque changement
Tutoriel ancien qui conseille utf8 partout Legacy non adapté à WP moderne Rester sur utf8mb4 et migrer proprement si nécessaire
Augmenter WP_MEMORY_LIMIT sans augmenter PHP WordPress demande plus, PHP refuse Aligner WP_MEMORY_LIMIT et memory_limit

Sécurité serveur

wp-config.php contient des secrets (DB + salts). La sécurité ici n’est pas “optionnelle”.

  • Ne versionnez jamais wp-config.php dans un dépôt Git public. Si vous faites du Git, utilisez un template (wp-config-sample.php) et injectez les secrets via variables d’environnement côté serveur.
  • Limitez les permissions : évitez 777. Sur Linux, 640 est un bon point de départ.
  • Bloquez les logs : si vous activez WP_DEBUG_LOG, empêchez l’accès HTTP à wp-content/debug.log (Nginx/Apache).
  • Rotation des clés : si vous suspectez une fuite, régénérez les salts. Oui, tout le monde sera déconnecté. C’est le but.
  • SSL partout : si vous forcez l’admin en SSL, assurez-vous que votre terminaison TLS est correcte et que les headers proxy ne sont pas forgeables.

Pour les permissions et bonnes pratiques générales, la page officielle est claire : developer.wordpress.org – Hardening WordPress.

Ressources

FAQ

Est-ce que je peux casser mon site en modifiant wp-config.php ?

Oui. Un seul caractère mal placé peut provoquer une erreur 500. Faites un backup du fichier, puis validez la syntaxe avec php -l wp-config.php.

Où coller exactement les constantes ?

Au-dessus de la ligne “C’est tout, ne touchez pas à ce qui suit”. Si vous les mettez en dessous, certaines peuvent être ignorées ou déclencher des effets inattendus.

Pourquoi je ne vois pas de debug.log alors que WP_DEBUG_LOG=true ?

Le fichier est souvent créé seulement à la première erreur. Vérifiez aussi que wp-content/ est inscriptible par PHP. Et contrôlez que votre serveur ne loggue pas ailleurs (logs PHP-FPM).

Quand faut-il régénérer les clés/salts ?

Après suspicion de fuite (backup exposé, accès FTP compromis, plugin malveillant), ou si vous voulez forcer une déconnexion globale. C’est une mesure de sécurité, pas un “tweak performance”.

DISABLE_WP_CRON : je l’active et plus rien ne part, c’est normal ?

Oui si vous n’avez pas ajouté un cron système. Activez un crontab qui appelle wp-cron.php régulièrement.

WP_MEMORY_LIMIT règle-t-il toutes les erreurs mémoire ?

Non. Il fixe la mémoire “demandée” par WordPress, mais PHP peut imposer un plafond plus bas. Vérifiez memory_limit côté PHP.

Dois-je définir WP_HOME et WP_SITEURL dans wp-config.php ?

Uniquement si vous avez un besoin précis (migration, domaine qui redirige mal, admin inaccessible). Sur un staging, ça peut vous gêner si l’URL change. Dans le doute, corrigez d’abord les valeurs en base (table wp_options).

Je suis sur Divi 5 / Elementor / Avada : wp-config.php change quelque chose ?

Indirectement oui : ces builders consomment plus de mémoire et déclenchent plus de tâches (imports, génération CSS, caches). Les constantes WP_MEMORY_LIMIT, WP_DEBUG_LOG et une stratégie cron propre font une vraie différence en dépannage.

Je peux éditer wp-config.php depuis l’éditeur de fichiers WordPress ?

Non (et c’est une bonne chose). Utilisez SFTP/SSH. Évitez les “file managers” web quand vous pouvez : surface d’attaque plus grande.

Que faire si je suis bloqué hors de l’admin après rotation des salts ?

Reconnectez-vous simplement. La rotation invalide les cookies existants, donc c’est attendu. Si vous ne pouvez pas vous connecter, cherchez plutôt un problème de cookies/HTTPS/proxy.

Comment revenir en arrière proprement ?

Restaurez le backup wp-config.php.bak..., puis vérifiez que le site répond. Si la panne venait d’une migration DB, restaurez aussi l’export SQL via WP-CLI.

Articles connexes

Submit a Comment

Your email address will not be published. Required fields are marked *