Gérer plusieurs configurations dans le wp-config.php
Il n’est pas toujours possible, voire souhaitable, de garder son wp-config.php identique entre l’environnement local et l’environnement de production.
Il y a d’un côté la solution désagréable, qui consiste à le modifier à chaque fois qu’on a besoin de le charger sur l’environnement de production (et à ne pas réoublier de le modifier si on continue en local… avec un jour le risque de charger le “wp-config.php” local à la place de celui de prod.
On peut jouer avec deux fichiers, en les renommant, mais si par hasard il y a trois environnements (développement, intégration et prod) il y a plus simple.
J’ai rajouté une routine au début de tous mes wp-config qui va déterminer la configuration en fonction du serveur sur lequel on se trouve.
J’ai donc deux fichiers, un avec la valeur de mes variables, le seul que je vais avoir besoin de modifier pour chaque site, et un avec la fonction (hyper simple) en php.
Pour la commodité, j’ai remis le code sur une seule page.
$setting_local = array(
'HTTP_HOST' => 'horizon-new',
'DB_HOST' => 'localhost',
'DB_NAME' => 'hrzwp',
'DB_USER' => 'root',
'DB_PASSWORD' => '',
'WP_SITEURL' => 'http://sitelocal/',
'WP_HOME' => 'http://sitelocal/') ;
$setting_prod = array(
'HTTP_HOST' => 'xxxxxxxxx',
'DB_HOST' => 'xxxxxxxxx',
'DB_NAME' => 'xxxxxxxxx',
'DB_USER' => 'xxxxxxxxx',
'DB_PASSWORD' => 'xxxxxxxxx') ;
//ensuite on teste on applique.
if ( getenv('HTTP_HOST') == $setting_local['HTTP_HOST'] )
{
define('DB_HOST', $setting_local['DB_HOST']);
define('DB_NAME', $setting_local['DB_NAME']);
define('DB_USER', $setting_local['DB_USER']);
define('DB_PASSWORD', $setting_local['DB_PASSWORD']);
define('WP_SITEURL', $setting_local['WP_SITEURL']) ;
define('WP_HOME', $setting_local['WP_HOME']) ;
define('WP_DEBUG', true) ;
}
else
{
define('DB_HOST', $setting_prod['DB_HOST']);
define('DB_NAME', $setting_prod['DB_NAME']);
define('DB_USER', $setting_prod['DB_USER']);
define('DB_PASSWORD', $setting_prod['DB_PASSWORD']);
define('WP_DEBUG', false) ;
}
Un petit include en début de fichier, et le tour est joué.
Commentaires : oui, je sais, je n’ai pas de password sur mon utilisateur root en local. En local, donc on s’en fout.
En ce qui concerne WP_DEBUG, il est par défaut à false, donc la dernière ligne de config pour le serveur de production est théoriquement inutile. Cela dit, on n’est jamais trop prudent.
Mes urls locales sont celles que j’ai définies pour WAMP dans le fichier http.conf et le fichier hosts de Windows. (Un jour je vous ferai un tuto). Leur config peut varier selon votre installation locale. Certains plugins écrivent en dur l’url complète du serveur dans la base de données, généralement wp_options. C’est baaaaad car il faut alors repasser à travers toute la table wp_options pour passer en prod. Là aussi, j’ai une petite routine php, qui fera l’objet d’un plugin.
Voilà, principe simple qui peut être multiplié avec autant de serveurs que nécessaire (et autant d’élément du wp-config.php, le guide est ici). On peut par exemple rajouter le préfixe de base….
Utiliser HTTP_HOST est un peu cavalier dans la mesure où c’est une valeur définit par le navigateur.
Utiliser une stratégie de versionnement cohérente est une solution beaucoup plus efficace et plus sécure.
Je vais certainement écrire un article la-dessus.
Vous pouvez toujours en partager les bases ici, et détailler un peu la réponse, non ?
Dans les grandes lignes, il suffit de versionner uniquement les répertoires contenant les themes et plugins perso (les autres sont suceptibles d’êtres modifié par les mises à jour de WordPress et des autres extensions).
On ignore le fichier wp-config.php (en le mettant dans le fichier .gitignore dans le cas de git). On configure correctement chacun de ces environnements.
Lors de passage du développement à la version de test ou à la production, le fichier wp-config.php n’est pas inclut dans le patch de mises à jour donc pas de risque de l’écraser.
Mais, cela implique un accès ssh et l’accès à la commande patch, ce qui malheureusement n’est pas toujours le cas avec certain hébergeur professionnel (si on peut les appeller comme cela).
Oui mais non :D
1. Le premier wp-config doit bien être uploadé à un moment ou à un autre, avec une config de prod différente de la config de test. Mon “truc” est justement pour cela, pour éviter d’avoir à le modifier à ce moment là. (c’est d’ailleurs le cas pour le fichier .htaccess)
2. Effectivement tout dépend de l’hébergement du client… et “parfois” ce genre de choses n’est pas accessible sur des mutualisés, ou des hébergements bons marchés . Et je laisse mes clients libres du choix de leur hébergeur.
3. Ne pas oublier que le fichier wp-config peut être modifié aussi d’une version à l’autre de wp (par exemple, le nombre de clé de sécurités qui augmentent régulièrement)
une simplification, en pseudo code :
$setting[‘local’] = array(
…
):
if ( condition permettant de savoir si on est en dev/prod/recette) {
$indice = ‘local’;
} else {
…
}
define(‘DB_HOST’, $setting[$indice]l[‘DB_HOST’]);
On peut même simplifier les 3 tests (pour déterminer l’environnement)
avec une recherche dans un tableau définissant l’indice à prendre.
Salut Marie-Aude,
Quelle bonne idée tu as eue. Je vais la tester sous peu. Merci pour ce partage.
Merci :)