Fichier wp-config.php – Une vue en profondeur sur la configuration de WordPress

L’un des fichiers les plus importants d’une installation WordPress est le fichier de configuration. Il réside dans le répertoire racine et contient des constantes et des instructions PHP qui font fonctionner WordPress comme vous le souhaitez.
Le fichier wp-config.php stocke des données comme les détails de connexion à la base de données, le préfixe de la table, les chemins d’accès à des répertoires spécifiques et de nombreux paramètres liés à des fonctionnalités spécifiques que nous allons examiner dans cet article.

• Le fichier de base wp-config.php
• Configuration de base : Modification du système de fichiers
• Fonctionnalités pour les développeurs : Mode de débogage et sauvegarde des requêtes
• Paramètres relatifs au contenu
• Taille de mémoire autorisée
• Mises à jour automatiques
• Paramètres de sécurité
• Autres paramètres avancés
• Verrouillage du fichier wp-config.php

Le fichier de base wp-config.php

Lorsque vous installez WordPress pour la première fois, on vous demande d’entrer les informations requises comme les détails de la base de données et le préfixe de la table. Parfois, votre hébergeur configurera WordPress pour vous, et vous n’aurez pas besoin d’exécuter manuellement la configuration. Mais lorsque vous exécutez manuellement l’installation qui se fait en 5 minutes, il vous sera demandé d’entrer certaines des données les plus pertinentes stockées dans le wp-config.

Voici un fichier wp-config.php de base :

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'database_name_here');

/** MySQL database username */
define('DB_USER', 'username_here');

/** MySQL database password */
define('DB_PASSWORD', 'password_here');

/** MySQL hostname */
define('DB_HOST', 'localhost');

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

define('AUTH_KEY',		'put your unique phrase here');
define('SECURE_AUTH_KEY',	'put your unique phrase here');
define('LOGGED_IN_KEY',		'put your unique phrase here');
define('NONCE_KEY',		'put your unique phrase here');
define('AUTH_SALT',		'put your unique phrase here');
define('SECURE_AUTH_SALT',	'put your unique phrase here');
define('LOGGED_IN_SALT',	'put your unique phrase here');
define('NONCE_SALT',		'put your unique phrase here');

$table_prefix  = 'wp_';

/* That's all, stop editing! Happy blogging. */

Généralement, ce fichier est généré automatiquement lorsque vous exécutez le programme d’installation, mais il arrive que WordPress n’ait pas les privilèges nécessaires pour écrire dans le dossier d’installation. Dans ce cas, vous devez créer un fichier wp-config.php vide, copier et coller le contenu de wp-config-sample.php, et définir les valeurs appropriées à toutes les constantes définies. Lorsque vous avez terminé, téléchargez votre fichier dans le dossier racine et exécutez WordPress.

Note : les constantes et les instructions PHP viennent dans un ordre spécifique que nous ne devrions jamais changer. Et nous ne devrions jamais ajouter de contenu sous la ligne de commentaire suivante :

/* That's all, stop editing! Happy blogging. */

Tout d’abord, viennent les constantes pour les informations de la base de données que vous auriez dû recevoir de votre hébergeur :

• DB_NAME
• DB_USER
• DB_PASSWORD
• DB_HOST
• DB_CHARSET
• DB_COLLATE

En suivant les détails de la base de données, huit clés de sécurité rendront le site plus sûr contre les pirates informatiques. Lorsque vous exécutez l’installation, WordPress génère automatiquement des clés de sécurité et des clés Salt, mais vous pouvez les modifier à tout moment, en ajoutant n’importe quelle chaîne arbitraire. Pour une meilleure sécurité, pensez à utiliser le générateur en ligne.

La variable $table_prefix stocke le préfixe de toutes les tables WordPress. Malheureusement, n’importe qui connaît sa valeur par défaut et cela pourrait ouvrir la base de données WordPress à une vulnérabilité, ce qui peut être facilement corrigée en définissant une valeur personnalisée pour $table_prefix lors de la configuration.
Pour changer le préfixe d’une table dans un site Web fonctionnel, vous devez exécuter plusieurs requêtes pour la base de données, puis modifier manuellement le fichier wp-config.php. Si vous n’avez pas accès à la base de données ou si vous n’avez pas les connaissances nécessaires pour créer des requêtes personnalisées, vous pouvez installer un plugin comme Change Table Prefix that qui renommera les tables de la base de données et les noms de champs, et mettra à jour le fichier de configuration sans risque.

Note : c’est une bonne pratique de sauvegarder les fichiers WordPress et la base de données même si vous allez changer le préfixe de la table avec un plugin.

Jusqu’à présent, l’analyse s’est limitée à la configuration de base. Mais nous avons à notre disposition de nombreuses constantes que nous pouvons définir pour activer des fonctionnalités, personnaliser et sécuriser l’installation.

Configuration de base : Modification du système de fichiers

Le système de fichiers de WordPress est bien connu des utilisateurs et des pirates. Pour cette raison, vous pouvez envisager de modifier la structure de fichiers intégrée en déplaçant des dossiers spécifiques dans des emplacements arbitraires et en définissant les URLs et chemins correspondants dans le fichier wp-config.
Tout d’abord, nous pouvons déplacer le dossier wp-content en définissant deux constantes. La premier définit le chemin complet du répertoire :

define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/site/wp-content' );

La seconde définit la nouvelle URL du répertoire :

define( 'WP_CONTENT_URL', 'http://example.com/site/wp-content' );

Nous pouvons déplacer uniquement le dossier plugins en définissant les constantes suivantes :

define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/wp-content/mydir/plugins' );
define( 'WP_PLUGIN_URL', 'http://example.com/wp-content/mydir/plugins' );

De la même manière, nous pouvons déplacer le dossier uploads, en définissant le nouveau chemin du répertoire :

define( 'UPLOADS', 'wp-content/mydir/uploads' );

Note : Tous les chemins sont relatifs à ABSPATH, et ils ne doivent pas contenir de barre oblique.

Une fois terminé, arrangez les dossiers et rechargez WordPress.

Il n’est pas possible de déplacer le dossier /wp-content/themes depuis le fichier wp-config, mais nous pouvons enregistrer un nouveau répertoire de thème dans un plugin ou un fichier de fonctions de thème.

Fonctionnalités pour les développeurs : Mode de débogage et sauvegarde des requêtes

Si vous êtes développeur, vous pouvez forcer WordPress à afficher des erreurs et des avertissements qui vous aideront dans le débogage de thème et de plugin. Pour activer le mode débogage, vous n’avez qu’à mettre la valeur WP_DEBUG à true, comme indiqué ci-dessous :

define( 'WP_DEBUG', true );

WP_DEBUG est défini à false par défaut. Si vous avez besoin de désactiver le mode de débogage, vous pouvez simplement supprimer la ligne, ou définir la valeur de la constante à false.

Lorsque vous travaillez sur un site en production, vous devriez désactiver le mode de débogage. Les erreurs et les avertissements ne devraient jamais être montrés aux visiteurs du site car ils peuvent fournir des informations précieuses aux pirates informatiques. Mais que faire si vous devez déboguer de toute façon ?
Dans de telles situations, vous pouvez forcer WordPress à conserver la mémoire des erreurs et des avertissements dans le fichier debug.log, placé dans le dossier /wp-content. Pour activer cette fonction, copiez et collez le code suivant dans votre fichierwp-config.php :

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

Pour que cette fonctionnalité fonctionne, nous devons d’abord activer le mode de débogage. Ensuite, en définissant WP_DEBUG_LOG à true nous forçons WordPress à stocker les messages dans le fichier debug.log, en définissant WP_DEBUG_DISPLAY à false nous les cachons à l’écran. Enfin, nous mettons à 0 la valeur de la variable PHP display_errors pour que les messages d’erreur ne soient pas affichés à l’écran. wp-config n’est jamais chargé depuis le cache. Pour cette raison, c’est un bon endroit pour remplacer les paramètres du fichier php.ini.

Remarque : C’est une excellente fonction dont vous pouvez profiter pour enregistrer les messages que WordPress n’affiche pas à l’écran. Par exemple, lorsque l’action publish_post est déclenchée, WordPress charge un script qui sauvegarde les données, puis redirige l’utilisateur vers la page d’édition de l’article. Dans ce cas, vous pouvez enregistrer des messages, mais pas les afficher à l’écran.

Une autre constante de débogage détermine les versions des scripts et des styles à charger. Définissez SCRIPT_DEBUG sur true si vous voulez charger des versions non compressées :

define( 'SCRIPT_DEBUG', true );

Si votre thème ou plugin affiche des données extraites de la base de données, vous voudrez peut-être stocker les détails de la requête pour une révision ultérieure. La constante SAVEQUERIES force WordPress à stocker les informations des requêtes dans le tableau $wpdb->queries Ces détails seraient affichés en ajoutant le code suivant au modèle du footer :

if ( current_user_can( 'administrator' ) ) {
        global $wpdb;
        echo '<pre>';
        print_r( $wpdb->queries );
        echo '</pre>';
}

Pour une analyse plus approfondie de cette fonctionnalité, reportez-vous à la section Comment créer des requêtes efficaces dans WordPress.

Paramètres relatifs au contenu

Lorsque votre site Web grandira, vous voudrez peut-être réduire le nombre de révisions d’articles. Par défaut, WordPress enregistre automatiquement les révisions toutes les 60 secondes. Nous pouvons changer cette valeur en définissant un intervalle personnalisé dans le wp-config comme suit :

define( 'AUTOSAVE_INTERVAL', 160 );

Bien sûr, vous pouvez également diminuer l’intervalle d’enregistrement automatique.
Chaque fois que nous sauvegardons nos modifications, WordPress ajoute une ligne à la table des messages, afin que nous puissions restaurer les révisions précédentes des articles et des pages. C’est une fonctionnalité utile qui pourrait se transformer en problème lorsque notre site grandira. Heureusement, nous pouvons diminuer le nombre maximum de révisions d’articles à stocker, ou désactiver la fonctionnalité totalement.
Si vous souhaitez désactiver les révisions d’articles, définissez la constante suivante :

define( 'WP_POST_REVISIONS', false );

Si vous voulez limiter le nombre maximum de révisions, ajoutez plutôt la ligne suivante :

define( 'WP_POST_REVISIONS', 10 );

Par défaut, WordPress stocke les articles, pages, pièces jointes et commentaires mis à la poubelle pendant 30 jours, puis les supprime définitivement. Nous pouvons modifier cette valeur avec la constante suivante :

define( 'EMPTY_TRASH_DAYS', 10 );

Nous pouvons même désactiver la corbeille, en mettant sa valeur à 0, mais considérez que WordPress ne vous permettra plus de restaurer le contenu.

Taille de mémoire autorisée

Occasionnellement, vous pouvez recevoir un message comme celui-ci :

Fatal error: Allowed memory size of xxx bytes exhausted …

La taille maximale de la mémoire dépend de la configuration du serveur. Au cas où vous n’auriez pas accès au fichier php.ini, vous pouvez augmenter la limite de mémoire juste pour WordPress en définissant la constante WP_MEMORY_LIMIT dans le fichier wp-config. Par défaut, WordPress essaie d’allouer 40 Mo à PHP pour les sites uniques et 64 Mo pour les installations multisites. Bien sûr, si la mémoire allouée en PHP est supérieure à 40 Mo (ou 64 Mo), WordPress adoptera la valeur maximale.

Cela dit, vous pouvez définir une valeur personnalisée avec la ligne suivante :

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

Si nécessaire, vous pouvez également définir une limite de mémoire maximale à l’aide de l’instruction suivante :

define( 'WP_MAX_MEMORY_LIMIT', '256M' );

Mises à jour automatiques

A partir de la version 3.7, WordPress supporte les mises à jour automatiques pour les versions de sécurité. Il s’agit d’une fonction importante qui permet aux administrateurs du site de garder leur site Web sécurisé en tout temps.

Vous pouvez désactiver toutes les mises à jour automatiques en définissant la constante suivante :

define( 'AUTOMATIC_UPDATER_DISABLED', true );

Ce n’est peut-être pas une bonne idée de désactiver les mises à jour de sécurité, mais c’est votre choix.
Par défaut, les mises à jour automatiques ne fonctionnent pas avec les versions majeures, mais vous pouvez activer toute mise à jour du coeur en définissant WP_AUTO_UPDATE_CORE comme suit :

# Désactive toutes les mises à jour du Coeur :
define( 'WP_AUTO_UPDATE_CORE', false );

# Active les mises À jour du coeur, mineures et majeures :
define( 'WP_AUTO_UPDATE_CORE', true );

La valeur par défaut est minor:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Une constante supplémentaire désactive les mises à jour automatiques (et toute mise à jour ou modification d’un fichier). Si vous réglez DISALLOW_FILE_MODS sur true, toutes les éditions de fichiers seront désactivées, même les installations et mises à jour des thèmes et des plugins. Pour cette raison, son utilisation n’est pas recommandée.

Paramètres de sécurité

Nous pouvons utiliser le fichier wp-config pour augmenter la sécurité du site. En plus des modifications apportées à la structure des fichiers que nous avons examinées ci-dessus, nous pouvons verrouiller certaines fonctionnalités qui pourraient ouvrir des vulnérabilités inutiles. Tout d’abord, nous pouvons désactiver l’éditeur de fichiers fourni dans le panneau d’administration. La constante suivante masquera l’éditeur :

define( 'DISALLOW_FILE_EDIT', true );

Note : considérez que certains plugins ne pourraient pas fonctionner correctement si cette constante est définie à true.

Une caractéristique de sécurité est l’administration par SSL. Si vous avez acheté un certificat SSL et qu’il est correctement configuré, vous pouvez forcer WordPress à transférer des données via SSL à n’importe quelle session de connexion et d’administration. Utilisez la constante suivante :

define( 'FORCE_SSL_ADMIN', true );

Consultez le Codex si vous avez besoin de plus amples informations sur l’administration par SSL.

Les deux autres constantes permettent de bloquer les requêtes externes et de lister les hôtes admis.

define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'example.com,*.anotherexample.com' );

Dans cet exemple, nous avons d’abord désactivé tous les accès des hôtes externes, puis listé les hôtes autorisés, séparés par des virgules (les caractères génériques sont autorisés).

Autres paramètres avancés

WP_CACHE mis à true inclut le script wp-content/advanced-cache.php. Cette constante n’a d’effet que si vous installez un plugin de cache persistant.

CUSTOM_USER_TABLE et CUSTOM_USER_META_TABLE sont utilisés pour définir des tables utilisateur personnalisées autres que les tables wp_users et wp_usermeta par défaut. Ces constantes permettent une fonctionnalité utile qui permet aux utilisateurs du site d’accéder à plusieurs sites Web avec un seul compte. Pour que cette fonctionnalité fonctionne, toutes les installations doivent partager la même base de données.

A partir de la version 2.9, WordPress supporte l’optimisation automatique des bases de données. Grâce à cette fonctionnalité, en réglant WP_ALLOW_REPAIR sur true, WordPress va automatiquement réparer une base de données corrompue.

WordPress crée un nouvel ensemble d’images chaque fois que vous modifiez une image. Si vous restaurez l’image d’origine, tous les ensembles générés resteront sur le serveur. Vous pouvez écraser ce comportement en réglant IMAGE_EDIT_OVERWRITE sur true, de sorte que, lorsque vous restaurez l’image originale, toutes les modifications seront supprimées du serveur.

Verrouillage du fichier wp-config.php

Nous savons maintenant pourquoi wp-config.php est l’un des fichiers WordPress les plus importants. Alors, pourquoi ne pas le cacher aux hackers ? Tout d’abord, nous pouvons déplacer le wp-config d’un niveau au-dessus du dossier racine de WordPress (un seul niveau). Cependant, cette technique est un peu controversée, alors je suggère d’adopter d’autres solutions pour protéger le dossier. Si votre site Web tourne sur le serveur Web Apache, vous pouvez ajouter les directives suivantes au fichier .htaccess :

<files wp-config.php>
order allow,deny
deny from all
</files>

Si le site fonctionne sur Nginx, vous pouvez ajouter la directive suivante au fichier de configuration :

location ~* wp-config.php { deny all; }

Remarque : ces instructions ne doivent être ajoutées qu’une fois l’installation terminée.

Si votre site Web a subi plusieurs migrations ou si vous l’avez acheté à quelqu’un d’autre, il est recommandé de créer un nouvel ensemble de clés de sécurité WordPress. Ces clés sont un ensemble de variables aléatoires qui améliorent le cryptage des informations stockées dans les cookies de l’utilisateur. Depuis WordPress 2.7, il y a eu 4 clés différentes : AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY et NONCE_KEY.

Par défaut, elles sont générées au hasard pour vous. Mais WordPress dispose en fait d’un outil gratuit que vous pouvez utiliser pour générer de nouvelles clés aléatoires. Vous pouvez alors simplement mettre à jour vos clés actuelles qui sont stockées dans votre fichier wp-config.php.

En savoir plus sur les clés de sécurité WordPress.

Et enfin, vous devriez vérifier et vous assurer que vos permissions sont durcies sur votre fichier wp-config.php. En règle générale, les fichiers du répertoire racine d’un site WordPress auront la valeur 644, ce qui signifie que les fichiers sont lisibles et modifiables par le propriétaire du fichier, lisibles par les utilisateurs du groupe de propriétaires de ce fichier et lisibles par tout le monde. Selon la documentation WordPress, les permissions sur le fichier wp-config.php doivent être définies à 440 ou 400 pour empêcher les autres utilisateurs du serveur de le lire. Vous pouvez facilement changer cela avec votre client FTP.

Résumé

Dans cet article, j’ai listé beaucoup de constantes WordPress que nous pouvons définir dans le fichier wp-config. Certaines de ces constantes sont d’usage courant et leurs fonctions sont faciles à comprendre. D’autres constantes permettent des fonctionnalités avancées qui nécessitent une connaissance approfondie de WordPress et de l’administration du site.

J’ai dressé la liste des fonctionnalités les plus courantes, en laissant de côté certaines fonctionnalités avancées dont nous pourrions discuter dans les prochains articles. Si vous souhaitez explorer des fonctionnalités et des constantes qui ne sont pas listées ici, n’hésitez pas à entamer une conversation dans les commentaires ci-dessous et nous analyserons cela.

Carlo Daniele Kinsta

Carlo is a passionate lover of webdesign and front-end development. He has been playing with WordPress for more than 20 years, also in collaboration with Italian and European universities and educational institutions. He has written hundreds of articles and guides about WordPress, published both on Italian and international websites, as well as on printed magazines. You can find him on LinkedIn.

• Site Web
• Twitter