Chapitre 4.2 — wp-config.php & constantes

⏱️ TL;DR — wp-config.php est le fichier de configuration racine de WordPress : identifiants de la base de données, clés de sécurité (salts), préfixe de tables, et une foule de constantes qui pilotent le comportement (débogage, mémoire, révisions, cache, environnement). C’est le premier fichier qu’on adapte à chaque install/migration, et le levier n°1 pour activer le mode développeur. Il ne doit jamais être versionné ni exposé (il contient des secrets).

🎯 Objectifs

• Comprendre le rôle et le contenu de wp-config.php.
• Connaître les constantes essentielles (base, sels, préfixe, débogage, mémoire).
• Activer proprement le mode développeur.
• Adopter les bonnes pratiques de sécurité (secrets, WP_ENVIRONMENT_TYPE).

1. Rôle et emplacement

wp-config.php se trouve à la racine de l’installation (ou un cran au-dessus du dossier web). WordPress le lit très tôt dans son démarrage (Partie 5) pour se connecter à la base et se configurer. Sans lui (ou mal renseigné), rien ne fonctionne.

2. Les blocs essentiels

// 1) Connexion à la base de données
define( 'DB_NAME', 'wordpress' );
define( 'DB_USER', 'root' );
define( 'DB_PASSWORD', 'root' );
define( 'DB_HOST', 'localhost' );
define( 'DB_CHARSET', 'utf8mb4' );
 
// 2) Clés & sels de sécurité (uniques par site — à générer)
define( 'AUTH_KEY',        '…chaîne aléatoire longue…' );
define( 'SECURE_AUTH_KEY', '…' );
// … 8 clés au total (AUTH, SECURE_AUTH, LOGGED_IN, NONCE × KEY/SALT)
 
// 3) Préfixe des tables
$table_prefix = 'wp_';
 
// 4) Réglages de développement (voir §3)
define( 'WP_DEBUG', true );

• Base de données : DB_NAME, DB_USER, DB_PASSWORD, DB_HOST — ce qu’on change à chaque migration (ch. 2.6).
• Sels (salts) : huit chaînes aléatoires qui chiffrent/signent les cookies et nonces. On les génère via le service officiel api.wordpress.org/secret-key/1.1/salt/. Les changer déconnecte tout le monde (utile en cas de compromission).
• $table_prefix : préfixe des tables (wp_ par défaut). Le personnaliser (wp_a1b2_) est une (petite) mesure de sécurité à la création ; le changer après coup demande de renommer les tables et d’ajuster des données.

⚠️ Piège — ne versionnez jamais wp-config.php. Il contient les identifiants de base et les sels. Il doit être dans .gitignore et hors de la racine web si possible. Exposer ce fichier = livrer les clés du site. En équipe, on versionne un wp-config-sample.php ou on injecte la config par variables d’environnement.

3. Constantes de développement (le mode dev)

Pour développer, activez le débogage (détaillé au ch. 4.5) :

define( 'WP_DEBUG', true );          // active les rapports d'erreur
define( 'WP_DEBUG_LOG', true );      // écrit dans wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // n'affiche PAS les erreurs à l'écran (les logue)
define( 'SCRIPT_DEBUG', true );      // charge les versions non minifiées des JS/CSS du cœur
define( 'SAVEQUERIES', true );       // enregistre les requêtes SQL (debug perf, coûteux)

• WP_DEBUG activé en dev, désactivé en prod (jamais d’erreurs affichées aux visiteurs).
• WP_DEBUG_LOG écrit dans un fichier plutôt qu’à l’écran → propre pour lire les erreurs.
• SCRIPT_DEBUG sert les assets non minifiés (utile pour déboguer le JS de l’éditeur/cœur).

4. Autres constantes utiles

💡 Pour un dev React — wp-config.php est votre .env + config runtime réunis. La bonne pratique moderne : ne pas coder les secrets en dur mais les lire depuis des variables d’environnement (getenv()), surtout en CI/déploiement — exactement comme vous le feriez avec process.env. Et WP_ENVIRONMENT_TYPE est l’équivalent de NODE_ENV : votre code peut faire if ( wp_get_environment_type() === 'production' ) pour adapter son comportement (logs, features, clés d’API de test).

5. Ordre et zone d’édition

Tout doit être défini avant la ligne :

/* C'est tout, ne modifiez rien au-delà. */
require_once ABSPATH . 'wp-settings.php';

Ajouter des define() après cette ligne n’aura aucun effet (WordPress est déjà démarré). Placez vos constantes au-dessus.

✏️ Exercices

1. Quelles constantes activez-vous pour développer, et laquelle faut-il désactiver en production ?
2. Pourquoi ne jamais committer wp-config.php dans Git ?
3. À quoi sert WP_ENVIRONMENT_TYPE et à quel concept Node correspond-il ?

🧠 Quiz de révision

Chapitre suivant : WP-CLI : la ligne de commande.