Astuces

WordPress et GIT : un wp-config mutualisé

wordpress-and-git

L’astuce pour faire cohabiter WordPress et GIT afin de mettre en place plusieurs environnements pour un même projet réside dans un wp-config mutualisé.

Edit :
Le 5&6 février 2016 se tenait le WCParis 2016 auquel j’ai été conférencier le samedi 6 février « WP & GIT : déployer un projet sur plusieurs environnements » à voir aussi ici.
J’y ai évoqué les principes de GIT puis enchaîné sur les méthodes telles que capistrano, wp-config mutualisé, deploy, deploybot …

PS : retrouvez un compte rendu intéressant de cette édition 2016 du WC Paris sur parisiennes.fr de Clémence  Borst.

 

Quand on est un développeur abouti, on utilise forcément un outil de versioning. Que ce soit svn ou git, en centralisation sur un serveur local ou chez un hébergeur, je pense qu’il ne faut pas se dispenser de son utilisation que je qualifie de triple emploi et que je compare souvent aux fonctionnalités d’un google doc :
outil de versioning : un historique permet de voir ce qui a été modifié et quand, ainsi pour une raison x ou y, il est possible de restaurer une version fonctionnelle, ou mieux comprendre les modifications ainsi réalisées.
outil collaboratif : toutes les personnes autorisées ont accès aux dernières versions partagées et peuvent visualiser les contributions apportées par chacun.
outil de déploiement: le partage/livraison et le contrôle sur l’intégrité des fichiers sont facilités.

Les basics sur GIT :

Je connais un tweeter, aussi développeur, pratiquant également du WordPress et qui plus est dans ma boîte, (le monde est petit) qui a déjà fait un assez gros travail, proposant ainsi un tutoriel complet pour s’initier à l’utilisation de GIT.
Allez lui rendre visite sur son blog (http://dev73.tweetpress.fr/dev/git-cest-la-vie.html) ça lui fera plaisir ! 🙂
Sinon, j’ai une autre source en anglais sur laquelle j’ai fait mes débuts : Learn version control with GIT

WordPress et GIT :

A partir de maintenant on considère que toutes les mises au point sont faites et on peut se lancer dans la structuration de son projet pour faire cohabiter WordPress sur de multiples environnements …

L’astuce consiste à créer autant de wp-config que d’environnements. Prenons l’exemple avec un écosystème disposant d’environnements de développement, qualification, pré-production et production. Nous allons donc avoir 4 wp-config : wp-config-dev, wp-config-qualif, wp-config-preprod et un wp-config.

1 – Des wp-configs dédiés

Chaque environnement a son propre wp-config avec ses variables qui lui sont propres, des fichiers bien particuliers à inclure et j’en passe. Nous allons donc créer un wp-config pour chaque environnement, que je nomme habituellement wp-config-{nom_de_l_environnement}.
Dans notre exemple nous aurions donc un wp-config-dev, wp-config-qualif, wp-config-preprod et c’est tout. Tout ce qui concerne la production reste dans le wp-config, ce n’est que dans un des trois autres cas qu’un autre wp-config prend le relais.

Le contenu de ces wp-config n’a rien de particulier, il peut reprendre l’équivalent du wp-config-sample et avec les configurations supplémentaires susceptibles de s’appliquer sur un environnement plus que sur un autre. Si on utilise ACF, on peut ajouter la variable ‘acf_lite’ qui vient masquer la page d’ACF dans le BO sur le serveur de pre-production et production, par exemple, afin que le client n’y parvienne pas par erreur et casse tout.

Voici les paramètres supplémentaires qui pourraient justifier cette implémentation sur un wp-config de production, clairement différent de celui de développement, par exemple :

/* Hide ACF BO page */
define( 'ACF_LITE', true );

define( 'WP_DEBUG', false );

/* Disable plugins editor & upgrades */
define( 'DISALLOW_FILE_MODS', true );
define( 'DISALLOW_FILE_EDIT', true );

/* Disable all core automatic updates */
define( 'WP_AUTO_UPDATE_CORE', false );

/* Production Facebook App ID */
define( 'FACEBOOK_ID', 154789625484554 );

/* Change revisions limitation & autosave interval */
define( 'WP_POST_REVISIONS', 5 );
define( 'AUTOSAVE_INTERVAL', 300 );

Maintenant que nos wp-configs sont créés pour tous nos environnements il faut faire en sorte que le bon se charge. Ces tests vont se réaliser dans le wp-config avant les variables de la production.

2 – Le wp-config, une plateforme tournante :

Il existe deux méthodes afin d’automatiquement détecter l’environnement et ainsi charger/utiliser des fichiers/variables propres à ce dernier. Le choix de l’une ou l’autre dépendra en grande partie de vos droits sur les serveurs. Il faudra donc recopier et adapter l’une des deux méthodes suivantes autant de fois que d’environnements. Cela se passe dans un premier temps dans le wp-config :
a – par détection d’un fichier :

if ( is_file( dirname( __FILE__ ) . '/../env_dev' ) ) {
     /* Development Server */

     if ( is_file( dirname( __FILE__ ) . '/../wp-config-dev.php' ) ) {
          require( dirname( __FILE__ ) . '/../wp-config-dev.php' );
     } elseif ( is_file( dirname( __FILE__ ) . '/wp-config-dev.php' ) ) {
          require( dirname( __FILE__ ) . '/wp-config-dev.php' );
     } else {
          die( 'No dev config' );
     }
} /* Add as many configs as you want with elseif statement */

Je recommande cette première méthode car on n’est jamais mieux servi que par soit-même. Il faut néanmoins avoir la possibilité de créer un fichier avec la commande suivante :

touch env_dev

Il faut de préférence créer ce fichier au-dessus de la racine WP (ici public_html).

env_file
Sinon à la racine de WP, en ajoutant le fichier au .gitignore du projet et en transformant la ligne 1 en :

is_file( dirname( __FILE__ ) . '/env_dev' )

b – par détection de l’url :

if ( 'dev_server.fr' === $_SERVER['SERVER_NAME'] ) {
     /* Development Server */

     if ( is_file( dirname(__FILE__) . '/../wp-config-dev.php') ) {
          require( dirname(__FILE__) . '/../wp-config-dev.php' );
     } elseif( is_file(dirname(__FILE__) . '/wp-config-dev.php') ) {
          require( dirname(__FILE__) . '/wp-config-dev.php' );
     } else {
          die('No dev config');
     }
} /* Add as many configs as you want with elseif statement */

La méthode que je recommande le moins, car l’url n’est jamais safe, mais nécessaire quand on n’a pas la main/accès au serveur.

3 – Conclusion

Cette mutualisation du wp-config permet de gagner en efficacité et en flexibilité, c’est pourquoi je la recommande dès lors que l’on veut travailler avec plusieurs serveurs en simultané et que l’on utilise GIT comme outil de versioning et mais également afin de réaliser des livraisons de modifications.

Bonus sur GIT :

  1. GIT n’est pas forcément un prérequis sur les serveurs sur lesquels on travaille. En cherchant sur internet j’ai trouvé une alternative que je dois encore beaucoup mieux benchmarker, mais que je peux d’ores et déjà recommander.
    C’est une extension qui permet depuis le BO d’un site d’avoir un tableau de bord pour GIT et faire les commandes de base. Vous trouverez l’extension ainsi qu’une review à l’adresse suivante : http://www.blogduwebdesign.com/plugin-wordpress/Revisr–Git-sauvegarder-production-plugin-Wordpress/1469
  2. Pour ceux qui sont encore sur SVN ou qui récupèrent de tels projets, je vous partage une méthode qui permet de convertir un SVN en GIT : https://github.com/nirvdrum/svn2git

 

Contribution :

Merci à Tita Créa pour la relecture.

3 Commentaires

Laisser un commentaire