Plusieurs configurations pour un seul site
Lors de son installation « 5minutes », WordPress crée un fichier nommé « wp-config.php » qui contient toutes les variables d’environnement nécessaire au bon fonctionnement du CMS. On pense notamment aux informations de connexion à la base de donnée, au préfixe des tables ou encore aux clé de sécurité pour le cryptage des données sensibles du site. Il faut savoir que le fichier wp-config peut faire bien plus que ça ! Toutes les fonctionnalités disponibles ne sont pas affichées par défaut, il faut se référer à l’article sur le sujet pour voir l’étendu des possibilités : https://codex.wordpress.org/fr:Modifier_wp-config.php
Ceci noté, la plupart du temps on ne travaille pas (on ne devrait jamais en fait) directement sur un site en production. Ça veut dire que l’on a une réplique du site soit sur une machine locale, soit sur un serveur de développement. On peut aussi avoir plusieurs environnements (local, dev, préprod, prod, …) ce qui implique potentiellement une configuration différente pour chacun de ces environnements….
C’est là que ça devient plus contraignant, comment faire fonctionner une même installation de WordPress dans plusieurs environnements ??
Un fichier par environnement
L’idée est assez simple : créer un fichier de config pour la production (wp-config.php) et un fichier supplémentaire pour chaque environnement (ex : wp-config-dev, wp-config-preprod, …). Chacun de ces fichiers contiennent les variables qui sont propre au contexte.
On peut imaginer des configurations qui ressemblent à peu près à ça :
Extrait du fichier wp-config.php (production)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
/* Maintenance & Sécurité */ define( 'FORCE_SSL_ADMIN', true ); define( 'AUTOMATIC_UPDATER_DISABLED', true ); define( 'WP_AUTO_UPDATE_CORE', false ); define( 'WP_DEBUG', false ); /* Performances */ define('WP_CACHE', true); define('COMPRESS_CSS', true); define('COMPRESS_SCRIPTS', true); define('CONCATENATE_SCRIPTS', true); define('ENFORCE_GZIP', true); |
Extrait du fichier wp-config-local.php
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
/* Infos de connexion */ define('DB_HOST', 'localhost'); define('DB_NAME', 'monsite_dev'); define('DB_USER', 'root'); define('DB_PASSWORD', ''); /* Maintenance & Sécurité */ define('FORCE_SSL_ADMIN', false ); define('AUTOMATIC_UPDATER_DISABLED', false ); define('WP_AUTO_UPDATE_CORE', false ); define('WP_DEBUG', true ); define('WP_ALLOW_REPAIR', true ); define('WP_SITE_URL', 'http://www.monsite.dev' ); define('WP_HOME', 'http://www.monsite.dev' ); /* Performances */ define('WP_CACHE', false); define('COMPRESS_CSS', false); define('COMPRESS_SCRIPTS', false); define('CONCATENATE_SCRIPTS', false); define('ENFORCE_GZIP', true); |
À noter dans ce dernier fichier les valeurs WP_SITE_URL et WP_HOME qui permettent de redéfinir l’adresse du site sans changer la valeur des options dans la base de données, plutôt pratique non ?
Utiliser wp-config.php comme gare de routage :
On a bien nos différents fichiers, mais il faut maintenant indiquer à WordPress lequel charger et quand. Pour cela on va modifier le fichier wp-config.php généré par WordPress en ajoutant les lignes suivantes (Bien sûr, adaptez ces lignes en fonction de vos besoins) :
|
1 2 3 4 5 6 7 8 |
If(is_file(dirname(__FILE__).'/wp-config-dev.php') { require_once(dirname(__FILE__).'/wp-config-dev.php') ; return ; //On ne charge pas la suite du fichier } elseif(is_file(dirname(__FILE__).'/wp-config-preprod.php') { require_once(dirname(__FILE__).'/wp-config-preprod.php') ; return ; //On ne charge pas la suite du fichier } |
Donc dans ce contexte, si aucun fichier spécifique à un environnement n’existe, WordPress charge le wp-config normalement, sinon il charge le fichier de l’environnement présent. On peut donc à partir de ce moment versionner le fichier de config de production sans soucis et sans pour autant se couper la possibilité d’avoir des variables d’environnement spécifiques au développement. Les fichiers wp-config-{env}.php sont bien sûr à ignorer dans le versionning afin de ne pas polluer de dépôt.
Une idée pour améliorer ce processus ? Vous faites complètement différemment ? N’hésitez pas à partager vos retours d’expériences !
Comme évoqué avec Jona sur le Slack FR, chez Be API nous utilisons également une méthode similaire pour avoir un projet versionné contenant tous les fichiers de configurations des différents environnements.
Elle avait été présentée au WordCamp Paris 2016.
Depuis, nous nous orientons le plus possible vers Composer pour la facilité d’utilisation et surtout la capacité à industrialiser la maintenance des plugins, themes, core, même s’il reste encore tout de même plusieurs fichiers de configurations à créer, par environnement.
Effectivement, j’ai vu passer cet article du WordCamp Paris 2016 dont je me suis inspiré pour faire le plan de cet article 🙂
C’est une super idée d’utiliser composer pour gérer le versioning du core, des plugins, etc… Par ailleurs j’avoue que je ne vois pas trop comment mettre ça en place au premier abord, est-ce que tu as une structure préconisée ? ça pourrait faire un super sujet d’article ici parce qu’à mon avis il y a plein de choses à dire là-dessus.
Par contre je crois que l’on aura vraiment du mal à s’affranchir de la création du plusieurs fichiers de config pour gérer chaque environnement…
C’est le sujet de ma future conf, si elle tombe, au WP Tech de cette année, donc un peu de patience
Mais clairement, Composer est un gain de temps immense. Il restera néanmoins toujours l’étape de « configuration » en créant les wp-config.
Cela me fait penser que lorsque l’on est sur un infra type AWS (Amazon Web Services), tout est stocké dans une global PHP, donc plus besoin de créer plusieurs fichiers
Pour répondre à ta question, tu trouvera un article très intéressant pour te lancer avec composer ici : https://roots.io/using-composer-with-wordpress