Skip to main content

Pour avoir expérimenter le développement de plugins avec wordpress, je me suis retrouvé confronté à une question intéressante : comment pouvoir coder en environnement local et prod? Disposant d’un serveur de versionnage, j’évoluais en environnements local, dev et prod. Fallait faire les commit et en plus, j’avais une application sous jahia (JEE). Durant son installation wordpress crée un fichier nommé « wp-config.php » qui contient toutes les variables d’environnement nécessaires au bon fonctionnement du CMS. Je parle notamment des informations de 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. Sur ce coup, il faut savoir que le fichier wp-config dans ses fonctions rémanentes fait bien plus que cela ! Pour connaître toutes ses fonctionnalités, il faut se référer  à cet article : article sur wordpress codex

Il faut donc configurer les environnements dont on a besoin. C’est là que ça devient plus contraignant, comment faire fonctionner une même installation de WordPress dans plusieurs environnements ??

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

  wp-config-dev pour l'environnement dev, 

  wp-config-preprod pour le preprod,

  wp-config-local pour le local.

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)

[pastacode lang="php" manual="%2F*%20Mode%20maintenance%20et%20crptage%20SSL%20*%2F%0Adefine(%20'FORCE_SSL_ADMIN'%2C%20true%20)%3B%0Adefine(%20'AUTOMATIC_UPDATER_DISABLED'%2C%20true%20)%3B%0Adefine(%20'WP_AUTO_UPDATE_CORE'%2C%20false%20)%3B%0Adefine(%20'WP_DEBUG'%2C%20false%20)%3B%0A%0A%2F*%20Performances%20*%2F%0Adefine('WP_CACHE'%2C%20true)%3B%0Adefine('COMPRESS_CSS'%2C%20true)%3B%0Adefine('COMPRESS_SCRIPTS'%2C%20true)%3B%0Adefine('CONCATENATE_SCRIPTS'%2C%20true)%3B%0Adefine('ENFORCE_GZIP'%2C%20true)%3B" message="" highlight="" provider="manual"/]

Extrait du fichier wp-config-local.php

[pastacode lang="php" manual="%2F*%20Infos%20de%20connexion%20%C3%A0%20la%20base%20de%20donn%C3%A9es%20*%2F%0Adefine('DB_HOST'%2C%20'localhost')%3B%0Adefine('DB_NAME'%2C%20'monsite_dev')%3B%0Adefine('DB_USER'%2C%20'root')%3B%0Adefine('DB_PASSWORD'%2C%20'')%3B%0A%0A%2F*%20Maintenance%20%26%20S%C3%A9curit%C3%A9%20*%2F%0Adefine('FORCE_SSL_ADMIN'%2C%20false%20)%3B%0Adefine('AUTOMATIC_UPDATER_DISABLED'%2C%20false%20)%3B%0Adefine('WP_AUTO_UPDATE_CORE'%2C%20false%20)%3B%0Adefine('WP_DEBUG'%2C%20true%20)%3B%0Adefine('WP_ALLOW_REPAIR'%2C%20true%20)%3B%0Adefine('WP_SITE_URL'%2C%20'http%3A%2F%2Fwww.monsite.dev'%20)%3B%0Adefine('WP_HOME'%2C%20'http%3A%2F%2Fwww.monsite.dev'%20)%3B%0A%0A%2F*%20Performances%20*%2F%0Adefine('WP_CACHE'%2C%20false)%3B%0Adefine('COMPRESS_CSS'%2C%20false)%3B%0Adefine('COMPRESS_SCRIPTS'%2C%20false)%3B%0Adefine('CONCATENATE_SCRIPTS'%2C%20false)%3B%0Adefine('ENFORCE_GZIP'%2C%20true)%3B" message="" highlight="" provider="manual"/]

À 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) :

[pastacode lang="php" manual="If(is_file(dirname(__FILE__).'%2Fwp-config-dev.php')%20%7B%0Arequire_once(dirname(__FILE__).'%2Fwp-config-dev.php')%C2%A0%3B%0Areturn%C2%A0%3B%20%0A%2F%2FOn%20ne%20charge%20pas%20la%20suite%20du%20fichier%7D%0Aelseif(is_file(dirname(__FILE__).'%2Fwp-config-preprod.php')%20%7B%0Arequire_once(dirname(__FILE__).'%2Fwp-config-preprod.php')%C2%A0%3B%0Areturn%C2%A0%3B%20%0A%2F%2FOn%20ne%20charge%20pas%20la%20suite%20du%20fichier%0A%7D" message="" highlight="" provider="manual"/]

 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.

J’ai rien inventé je vous rassure.