Le fichier WP-Config permet à WordPress de se connecter à la base de données. Mais on va voir qu’il a aussi d’autres usages.
Sommaire du cours
Dans le cours précédent, nous avons vu comment activer le mode débug depuis le fichier wp-config.php de WordPress. On va maintenant analyser ce fichier un peu plus dans les détails et je vous donnerais quelques améliorations que vous pourrez appliquer à tous vos projets.
Pour rappel ce fichier est généré lors de l’installation de WordPress, qui va utiliser pour base le fichier wp-config-sample.php.
Ouvrez votre fichier wp-config.php avec votre éditeur de code préféré, et analysons-le.
Le fichier WP-config en détails
La connexion à la base de données
Tout d’abord on va retrouver les identifiants de connexion à la base de données, que l’on a indiqués lors de l’installation :
On retrouve : le nom de la base, l’utilisateur, le mot de passe et l’hôte (qui souvent est localhost).
On retrouve aussi l’encodage. Aujourd’hui sur le web l’encodage de caractères par défaut est UTF-8 car il a la particularité de prendre en compte tous les caractères non latins, c’est-à-dire les accents, les caractères spéciaux et les autres alphabets comme le cyrillique. Il n’y a donc aucune raison de changer cette valeur.
Enfin la collation reste généralement vide car c’est la base de données qui la définira d’elle même. Cette valeur n’est utilisée que dans des cas spécifiques.
Les clés de salage
On a vu précédemment que les mots de passe dans la base de données ne sont pas stockés en clair, ils sont chiffrés par une fonction PHP qui le transforme en une série de chiffres et lettre d’une quarantaine de caractères. Ce chiffrement est dû en parti aux clés uniques définies dans le fichier de configuration de WordPress dont voici un exemple :
Afin de comprendre le but de clés uniques dites de « salage », faisons une petite aparté chiffrement/cryptographie.
Aparté: Comprendre le chiffrement
Afin de ne pas garder des informations en clair dans la base de données (entre autres usages), on va utiliser une fonction de chiffrement, comme le SHA-1 (qui est utilisé dans les certificats SSL notamment) qui va transformer votre mot de passe, par exemple « coucou » en une série de chiffres et lettres comme « 1d5F3kP12… ».
Si je change un seul caractère, en mettant cette fois « Coucou » (avec un C majuscule), le chiffrement sera complètement différent, par exemple « 3Vb98df4… ».
Le principe est qu’une fois chiffré, il est impossible de retrouver le texte initial. Mais le problème est que « coucou » générera toujours « 1d5F3kP12… » donc quelqu’un qui s’amuserait à créer un dictionnaire des relations entre le texte original et sa version chiffrée pourrait facilement décoder un mot de passe crypté.
C’est là qu’interviennent les clés de salage (salt en anglais). La clé est générée aléatoirement à l’installation et est ajoutée à chaque mot de passe avant chiffrement. De cette manière ce n’est plus seulement « coucou » qui est chiffré mais « coucou » + la clé.
Impossible du coup pour un pirate de retrouver la correspondance ! Mais alors comment vérifier le mot de passe lors de la connexion si celui-ci est chiffré ?
À la connexion, WordPress prend le mot de passe que vous avez saisi, ajoute la clé de salage et lance le chiffrement : si la clé obtenue est la même que celle stockée en base, c’est que la personne a rentré le bon mot de passe et le système le connecte !
Si la cryptographie et la sécurité web vous intéressent, il y a pleins de tutos et vidéos sur Internet à ce sujet passionnant quoiqu’un peu complexe.
Pour en revenir à WordPress, il génère 8 clés différentes qui ont chacune leur usage dans le site. AUTH_KEY est utilisée lors de l’authentification alors que NONCE_KEY permet de générer un code à usage unique, les nonces WordPress : que l’on utilise pour certifier la provenance des données du formulaire depuis le site et pas ailleurs (les fameuses failles XSS).
Ces clés participent à la sécurité du CMS. Elles sont générées à l’installation grâce au service de clé secrète de wordpress.org : https://api.wordpress.org/secret-key/1.1/salt/.
Si cela vous parait nébuleux, il vous suffit de savoir que WordPress est bien sécurisé grâce à ces clés !
Le préfixe des tables
Cette information est proposée lors de l’installation. Le préfixe de table par défaut est wp_. On a vu son utilité dans le cours sur l’installation de WordPress en local.
Debug
Si vous arrivez directement ici depuis Internet je vous conseille de consulter le cours précédent, dédié à ce paramètre Debug. Sinon rien d’autre à voir à ce propos !
That’s all !
Après cette indication : ne touchez à rien ! Vous risqueriez de casser WordPress. Ici il est simplement question de définir le chemin absolu, ABSPATH et aller chercher le prochain fichier du coeur pour continuer l’exécution de WordPress.
Le chemin absolu est souvent utilisé dans WordPress, cela permet au coeur, aux thèmes et extension d’inclure un fichier en allant le chercher par rapport au dossier de base dans lequel se trouve actuellement le site dans le système d’exploitation.
Quelques améliorations utiles
J’ai quelques paramètres supplémentaires en stock que j’ajoute à chaque projet pour affiner encore cette configuration. Même si en l’état le fichier wp-config suffit, ces petites améliorations ont leur utilité. C’est Tony qui les propose :
Le conseil de Tony Archambeau
Fondateur de l’agence ADALGO
Pour éviter le gonflement de la base de données :
– limitez les révisions avec WP_POST_REVISIONS
– allongez la durée des sauvegardes automatiques avec AUTOSAVE_INTERVAL
Pour éviter les mauvaises manipulations de la part des utilisateurs, ou des problèmes de sécurité, pensez à désactiver l’éditeur de fichier au sein du back office de WordPress, grâce à DISALLOW_FILE_EDIT.
Et enfin avant la mise en ligne du site, pensez à désactiver l’affichage des erreurs avec WP_DEBUG.
Désactiver l’éditeur de fichiers
Le problème : un utilisateur avec les droits d’administrateurs peut, depuis l’administration (dans Apparence > Éditeur), accéder à un éditeur et modifier les fichiers du thème ou des extensions.
Depuis WordPress 4.9 un panneau indique que c’est une zone dangereuse. A défaut de mieux c’est déjà bien.
Mais heureusement, vous allez complètement pouvoir désactiver cette fonctionnalité grâce à une ligne à ajouter dans votre wp-config.php :
Je met cette ligne dans tous les projets, même les miens !
Limiter le nombre de révisions
Quand vous écrivez un article, WordPress va créer des sauvegardes automatiquement à intervalles réguliers. C’est très pratique pour revenir à une version antérieure d’un article ou récupérer un ancien contenu en cas de problème.
Cependant à très long terme toutes ces révisions peuvent alourdir drastiquement la base de données. Afin d’éviter cela vous pouvez limiter le nombre de révisions à conserver pour chaque article :
Espacer les enregistrements automatiques
Et si vous voulez également avoir moins d’enregistrements automatiques, vous pouvez augmenter l’intervalle d’enregistrement qui est fixé à toutes les 60 secondes par défaut. Montez la valeur à 300 pour ne lancer un enregistrement que toutes les 5 minutes.
Définir l’adresse du site
Par défaut, l’URL du site est enregistrée dans 2 valeurs en base de données, dans la table wp_options : siteurl et home.
Vous pouvez également les configurer directement depuis le fichier wp-config.php afin que ce soit plus simple à changer lors d’un passage en ligne. Il suffit pour cela de définir ces deux lignes :
Du coup les valeurs en base seront désormais ignorées.
Être fonctionnel pour l’environnement local et en ligne
Et enfin, on va reprendre la petite astuce donnée dans le cours sur le debug et l’étendre à nos identifiants de connexion, afin d’avoir un fichier qui fonctionne autant en local qu’en ligne !
Si on est en local, on applique un jeu de paramètres contenant les informations de connexion à la base et l’adresse du site alors que si on est en ligne, on applique un autre jeu.
Vous êtes prêt ! Vous avez toutes les cordes à votre arc pour installer WordPress et comprendre comment il fonctionne. On va maintenant entrer dans le vif du sujet et apprendre enfin à créer notre premier thème.
Alexis
Le 6 octobre 2019
Hello, d’abord merci pour t’es astuce ! Pour le petit script pour gérer la préprod & la production, tu le place à la fin avant That’s all ou tu peux le mettre au même endroit que la BDD ? Et pour DB_Charset et DB_Collate tu le mets ou ?
Maxime BJ
Le 7 octobre 2019
Il faut le mettre à la place des identifiants originaux (qu’il faut donc enrober dans ce code) et pour le charset tu y laisses en dehors comme ça ne change pas entre la préprod et la prod.
Al
Le 29 avril 2020
Salut ! Je vois que sur tes exemples, les fichiers wordpress sont en français, or avec l’installation automatique ils sont en anglais, y’a t’il un moyen de les mettre en français avec Local by Flywheel ? Merci !
Maxime BJ
Le 29 avril 2020
J’ai simplement passé le site en Français (Réglages > Général). Local ne propose pas le choix de la langue lors de l’installation en effet (même si j’ai soumis l’idée à plusieurs reprises) mais rien n’empêche de changer la langue après coup.
Al
Le 29 avril 2020
J’avais fait ça et, effectivement, la page d’administration est en français, mais les fichiers (comme wp-config ) reste en anglais.
Tt
Le 14 octobre 2020
Bonjour
Je suis nouveau sur WP, j’ai envie de récupérer tous les command depuis la création du site(il a 1 ans ) mais le problème ce que dans le bases de données phpMyAdmin, il n’affiche que des infos sur les opérations en 2 mois, Y’ a t’il un moyen pour récupérer tous les info ? Merci
Maxime BJ
Le 14 octobre 2020
Ce n’est pas le bon cours où poser la question. Plus loin on abordera la WPQuery est ça qui va t’aider. Mais si tu parles de WooCommerce, je ne l’aborde pas encore dans cette formation. Il faudra regarder sur la documentation WooCommerce pour cela
Kline
Le 8 août 2021
Et moi qui trouvait l’éditeur de code de l’administration bien pratique pour éditer mes plugins sans me prendre la tête… Mince alors.
Maxime BJ
Le 8 août 2021
Tu peux, mais dis-toi bien que c’est loin d’être l’approche idéale pour coder son plugin. Il vaut mieux le faire en local, avec un vrai IDE comme PHP Storm ou VSC, utilise un versionnement comme Git…
Kline
Le 9 août 2021
Oui j’utilise Vim personnellement, mais disons que pour des retouches rapides je le trouvais assez pratique. Mais effectivement ce n’est pas très optimal, je vais suivre les conseils.
Au fait question totalement auxiliaire : est-il possible de s’inscrire sur votre site pour garder une trace de la progression dans la formation ? J’ai cherché mais je ne vois que la page connexion en haut à droite. Merci d’avance 🙂
Chloe GABRIEL
Le 10 septembre 2021
Bonjour !
Tout d’abord, merci beaucoup d’avoir créer ce cours c’est pile ce qu’il me fallait !
J’ai une question technique : dans la condition au niveau du else (ligne 18), peux-tu me dire à quoi correspond la valeur ‘mysql.db.52’ ? Est-ce que tu as créé une nouvelle DB sur Adminer avec le logiciel Local ?
Je te remercie d’avance pour ta réponse !
Chloe G.
Maxime BJ
Le 12 septembre 2021
J’ai en effet repris les informations générées par le fichier wp-config.php du site Local. Ce n’est donc pas moi qui ait créé la base, elle a été créée par Local lors de la création du site.
hugogogo
Le 18 septembre 2021
salut maxime, j’ecris bcp de commentaires donc je me repete : merci enormement pour ce cours !
j’ai essayé de mettre les deux lignes pour les urls :
define( ‘WP_HOME’, ‘http://some_url.local’ );
define( ‘WP_SITEURL’, ‘http://some_url.local’ );
mais ca a “cassé” mon site (j’ai mis une url au hasard pour essayer de comprendre comment ca marchait), donc j’ai enlevé ces lignes de mon fichier wp-config.php, mais le site ne revient pas a la normal : j’ai un message de bienvenue de nginx, alors qu’avant j’avais mon theme qui s’affichait correctement :/
Maxime BJ
Le 18 septembre 2021
Vérifie que tu as bien enregisté le fichier après le retrait de ces lignes. Désormais ce sont les valeurs dans la table wp_options qui sont prises en compte. Contrôle qu’elles sont correctes là aussi.
hugogogo
Le 18 septembre 2021
j’avais bien enregistré et les valeurs de la base de donnee wp_options etaint les bonnes, mais j’ai fini par remarquer dans le debugger que je recevais un statut `301 permanently moved (cached)` et que je n’avais pas de probleme en connexion privée, alors j’ai vidé le cache de mon navigateur et tout est revenu dans l’ordre 🙂
Mister PC
Le 28 septembre 2021
Salut Maxime,
Merci pour ton tuto, c’est VRAIMENT le seul qui soit à ce point complet. Bravo, super-bon boulot !!!
Juste une autre bonne pratique à propos de wp-config.php : déplacer ce fichier dans un emplacement du serveur situé hors de l’arborescence du site et l’appeler depuis le wp-config.php original de WordPress avec le contenu suivant :
<?php
if (!defined('ABSPATH')) {
define('ABSPATH', dirname(__FILE__) . '/');
}
require_once('/serveur/external/path/to/wp-config.php');
Cela permet, en cas de serveur web hacké (bien que fort peu probable, même si ça peut rester possible suite à une faille d'Apache ou NginX) de ne pas compromettre les accès à la base… et de donner l'accès aux clés de salage utilisées pour l'encryptage des mots de passe des utilisateurs inscrits, qui, comme chacun sait, n'utilisent pas toujours des mots de passe suffisamment forts, et parfois même identiques sur différents sites…
Maxime BJ
Le 28 septembre 2021
Ce n’est pas une super bonne pratique non : en pensant régler un problème, tu l’as en fait seulement décalé. Si un hack est capable de lire le wp-config, il sera également capable d’inclure ton fichier (si WordPress peut le faire, le hack ayant accès à WP le peut aussi). D’ailleurs, si c’est pour faire ça, autant faire les choses bien et utiliser les variables d’environnement : c’est exactement leur raison d’être. Il faut tout de même garder à l’esprit qu’un site hacké doit être considéré comme totalement compromis, dès que tes mesures de protection sont passées, ce genre de sécurité n’arrêtera plus rien : c’est déjà trop tard.
Jean Claude
Le 15 décembre 2021
Bonjour,
Débutant au ras des pâquerettes. J’ai installé WordPress en local. J’ai changé son nom en le nomment du nom de mon site. J’ai mis ce dossier dans le dossier WWW de Wamp. En allant dans localhost, la page de mon site s’ouvre. Mais comment accéder au tableau de bord de WordPress, pour pouvoir continuer mon site ?
Wordpress me parait pas mal mais comment l’utilise-t-on ?
Merci pour votre réponse.
Merci pour votre Tuto vraiment très instructif.
Maxime BJ
Le 15 décembre 2021
Salut Jean Claude. Ces cours pour développeurs sont destinés à ceux qui maitrisent déjà bien le CMS. Si tu débutes, je te conseille plutôt mon autre formation WordPress chez WPChef (prise en charge CPF possible), ainsi que les tutoriels de WPMarmite.
Vincent
Le 22 novembre 2023
Hello, quand je mets ce bout de code dans la première condition :
define(‘WP_HOME’,’http://monsite.local’);
define(‘WP_SITEURL’,’http://monsite.local’);
J’ai le fameux white screen of death… j’ai passé une journée à essayer de comprendre d’où ça venait, aucune idée… si jamais vous aviez une piste… ! Merci
Maxime BJ
Le 22 novembre 2023
Normalement tu n’en as pas besoin pour que ça fonctionne. LocalWP définit directement les bonnes URL dans la base plutôt que dans le fichier de configuration (dans la table wp_options, ce sont les 2 premières valeurs).