Jean ROCHARD
Je partage ma passion de Wordpress dans des articles techniques sur les plugins, thèmes, nouveautés geek et optimisation SEO "on-site".
Jean ROCHARD

@jean_rochard

Chez Terre Digitale, on mange du Wordpress dès le petit-dej'.
Petit guide pour mettre en place les Facebook Instant Articles à partir de vos posts Wordpress : https://t.co/lSbzdM6z9j - 7 mois ago

Ces dernières semaines, les mises à jour ont été nombreuses sur les sites WordPress. Il y a eu des correctifs de failles de sécurité pour le « core » et de nombreuses extensions ont également été mises à jour. Vous avez aussi peut être en même temps mis à jour votre site avec une version responsive de votre thème puisque Google vous avait laissé jusqu’au 21 avril 2015 pour le faire. Bref, cela commence à faire beaucoup de modifications en peu de temps !

Comme de nombreux webmasters WordPress, vous avez peut être quelque peu hésité avant de valider ces mises à jour directement en production et vous avez croisé les doigts pour ne pas avoir à remonter un backup en urgence suite à une incompatibilité… Parcequ’il faut le dire : un backup c’est bien (et indispensable) mais remettre en ligne une version stable, c’est autre chose : il faut nettoyer l’ancien WordPress, la base de données, retrouver une version qui fonctionne, remonter les fichiers par FTP et remonter une base. Pas moins de 2h d’indisponibilité à compter, si tout se passe bien (car c’est souvent à ce moment que votre connexion ADSL vous lâche…).

Pour éviter cela, il existe une solution robuste comme mettre en place un backup avec contrôle de versionBlogvault en est l’exemple le plus connu et vous proposera un service avec restore automatique pour 9$ / mois. Très pratique, très pro, mais un peu cher (sauf quand on s’en sert !). On peut aussi faire confiance à des solutions d’hébergements qui proposent nativement ce type de services comme WpEngine mais pour 29$ / mois. Ce que je vous propose ici, c’est une solution gratuite utilisant Git, un outil de contrôle de version très puissant.

Les scripts que je vous montre ici seront adaptés à un serveur simple hosting chez gandi mais ils sont transposables sur d’autres environnements bien sûr.

 

Pourquoi Git est une bonne idée

Git est un outil qui va centraliser les sources d’un projet sur un espace que nous nommerons « repository » , qui va gérer les versions des fichiers et permettre de créer des copies de ce répertoire pour notamment travailler à plusieurs. Classiquement, Git ne sert pas à déployer un projet et n’est pas installé sur un environnement de production. On utilise plutôt un FTP ou un outil comme FTPloy pour cela.

Les commandes Git sont installées sur le serveur Gandi simple hosting (de la même façon chez OVH à partir de l’offre pro) et Gandi vous propose aussi un repository Git sur votre instance (accès SSH+GIT). Nous n’allons pas l’utiliser car ce repository est trop lié à l’instance et ne sera donc pas adapté pour déplacer le site vers un autre hébergement ou une autre instance. Ce repository est adapté lorsqu’on utilise Git dans un contexte de développement / déploiement.

Lorsque l’on utilise et installe Git pour faire du backup sur un hébergement en production, il faut prendre en compte la sécurité car on peut avoir vite fait de se mettre en danger. Pour WordPress, Git est une bonne idée tout de même car :

  • si on met Git au niveau de la partie non public d’un virtual host (le répertoire avant « htdocs » chez Gandi, ou avant « www » chez OVH, ou avant « public_html » chez d’autres hébergeurs), les informations liée au repository seront préservées et non visibles.
  • même si Git ne préserve pas les permissions des fichiers par défaut, il réattribue lors d’un checkout (lorsque l’on rapatrie les fichiers sur l’hébergement) les permissions 644 aux fichiers et 755 aux répertoires ; ce qui est parfait pour WordPress. Il ne reste plus (éventuellement) qu’à remettre le fichier wp-config.php en 600 (seul le propriétaire a les droits de lecture et écriture) et le tour est joué. Vous pouvez lire cet article sur les permissions conseillées pour WordPress si le sujet vous intéresse.

Etape 1 : se créer un remote repository sur GitHub ou BitBucket

Ces 2 solutions vous proposent d’héberger vos repository Git de façon distante et sécurisée. Il faudra bien sûr mettre vos sources dans un répertoire privé ! L’avantage de BitBucket est d’être gratuit en ce qui concerne les repository privés ; alors que GitHub vous les facturera mensuellement.

Une fois votre compte activé, créez votre repository en cochant bien la case « private » ; et nettoyez les fichiers par défaut (seulement pour le premier repository créé) en allant dans « source » puis « Edit -> delete ».

Etape 2 : faire un peu de ménage dans WordPress

Avant de vous lancer, je vous conseille de faire un peu nettoyage sur votre site (faite un backup avant, pas avec Git encore, mais un backup quand même !). Cela vous permettra d’avoir un site plus léger à archiver. Pour cela (et entre autres) :

  • supprimez les thèmes inutiles (par SSH ou FTP)
  • supprimez les plugins inutiles (désolé, mais pas la peine de garder Hello Dolly !)
  • nettoyez votre base de données des révisions inutiles et autres commentaires indésirables (par le plugin wp-optimize par exemple)

Profitez en aussi pour repérer les répertoires de cache (comme htdocs/wp-content/cache/ pour le plugin W3 Total Cache) ou tout autre répertoire de cache qui pourrait être géré directement par le thème (oui ça arrive !). Vous noterez leur chemin pour les exclure des sources à contrôler.

Etape  3 : réaliser le premier push complet initial

Je vais vous proposer d’utiliser dans la suite le plugin « revisr » pour gérer quotidiennement le backup de votre site sur votre repository Git mais il peut arriver qu’il fonctionne mal lors de l’import inital d’un WordPress complet (requête trop longue).

Je vous propose donc un script bash pour faire cette première initialisation (exécutez le sous votre entière responsabilité !). Pour le récupérer :

cd web/vhosts/VOTRE_NOM_DE_DOMAINE
curl -O https://raw.githubusercontent.com/benefacere/wpgit/master/wpgitpush.sh

Placez vous à la racine de votre vhost (PAS dans htdocs) et lancez le script :

bash wpgitpush.sh mode gituseremail gitusername

Voici les paramètres :

1) « mode » prend soit la valeur « justcommit » soit la valeur « full ».

  • En mode « justcommit », le script archive les différences par rapport au repository sans poser aucune question. C’est un mode qui ne sert pas dans le cadre de cet article puisque c’est le plugin revisr qui va se charger de ce genre de choses.
  • En mode « full » (celui qui est à choisir pour cette étape d’initialisation), le script vous posera des questions :
    • faire un dump de la base ? Si oui, il faudra indiquer le nom de la base et le mot de passe du compte root d’accès ; ensuite le script sera zippé et placé dans le répertoire ./sqldump.
    • le chemin du remote repository ? Si Git n’a pas été paramétré encore, il faudra saisir le chemin du repository distant (exemple sur BitBucket https://NOM_USER:MDP_USER@bitbucket.org/NOM_COMPTE/NOM_REPO.git). Vous pouvez inclure votre mot de passe vers votre repository mais il sera stocké en clair dans le répertoire « .git » (même si en le mettant à la racine et non dans htdocs, le risque d’intrusion est réduit).
    • faire un tag ?

2) « gituseremail » est le mail de l’utilisateur git

3) « gitusername » est le nom de l’utilisateur git

Ce script va également ajouter un fichier « .gitignore » qui contient les chemins à exclure de l’archivage. Personnalisez le pour ne pas archiver les fichiers que vous avez identifiés à l’étape 2. A vous de voir si vous incluez ou non le fichier wp-config.php (il contient vos identifiants de connexion à la base de données).

Pour résumé, lancez ce script en mode « full », choisissez de ne pas faire de dump de la base de données et de faire un tag nommé par exemple v1.0 .

A l’issue de ce script, toutes vos sources seront sur le repository distant. Comme il est effectué de serveur à serveur, ce traitement ne prendra généralement que quelques secondes (au pire minutes) là où un transfert FTP aurait pris presque des heures.

Etape 4 : mettre en place le backup avec le plugin revisr

Nous allons maintenant installer le plugin revisr. C’est un plugin très bien documenté qui vous permet d’utiliser git soit comme outil de déploiement lorsque vous faites du développement, soit comme outil de backup pour votre site WordPress. C’est ce qui nous intéresse ici !

Avant d’installer revisr, je vous conseille de déplacer le fichier wp-config.php et le mettre au niveau du répertoire racine de votre vhost ; c’est à dire au même niveau que votre répertoire « .git » . Ce n’est pas obligatoire mais c’est plutôt bon pour la sécurité (ce fichier n’est plus accessible sur un dossier public) et WordPress sait par défaut aller le chercher à cet endroit. Cette configuration vous permettra de n’avoir quasiment rien à faire pour paramétrer revisr.

En effet, le plugin reprend la configuration que vous avez mise dans le répertoire .git et sera donc déjà configuré grâce à l’étape de push initial.

revisr

Il ne vous reste qu’à configurer sur l’onglet « General » l’option « automatic backup schedule » (quotidien ou hebdomadaire) et la notification par mail éventuelle. Ensuite, sur l’onglet « Remote », cochez la case pour le push automatique (quand une modification sera faîte sur votre hébergement, elle sera donc automatiquement archivée sur git).

Côté base de données, revisr se chargera de créer des scripts et de les archiver avec les autres fichiers.

Et maintenant, que faire avec mes backups sous Git ?

Très bien, vous avez maintenant un backup différentiel, avec gestion des versions. Mais comment faire un restore ? C’est plutôt simple avec revisr pour un restore partiel (c’est à dire revenir à une version antérieure) ; vous allez sur le détail d’un commit passé et stable et vous cliquez sur le bouton « Revert » :

revert_commit

Ce fonctionnement n’entraînera pas la création d’une nouvelle branche (le revert entraîne juste un checkout « détaché » ), et revisr s’occupera de récupérer la version demandée des fichiers sur votre hébergement et de la base de données. Attention, ce n’est pas non plus complètement sans risque… et il vous faudra voir comment poursuivre ensuite car le prochain commit reprendra sa place en tête de la branche principale. A vous de voir pour refusionner en refaisant une partie du travail, ou pourquoi pas créer une nouvelle branche… A partir de là, je reconnais que ça se complique un peu si on n’est pas développeur ; mais c’est très pratique et l’outil est très souple quand on sait ce qu’on fait.

Pour déplacer son site et le changer d’hébergement, l’avoir sous Git est également très pratique ; puisque quelques commandes vous permettront de le rapatrier sans le moindre délai et sans corvée FTP. Vous pouvez aussi imaginer redéployer votre site sur un environnement de test (sur une autre URL donc) facilement. Bref, plein de perspectives pour tout webmaster un peu développeur !

Je vous propose par exemple un script assez « agressif » puisqu’il supprime tout sur son passage (fichiers + base + user) ; mais qui permettra de redéployer un site WordPress sur un Gandi Simple Hosting en quelques instants (base incluse) pour peu que vous ayez bien sûr fait le « push » avec le premier script que je présente ici. Attention, à ne pas essayer sans avoir regardé ce que fait le code ! C’est ici : https://github.com/benefacere/wpgit/blob/master/wpgitclone.sh

Si vous ne vous sentez pas une âme de développeur aujourd’hui, regardez blogvault, mais sinon git est à essayer pour sa souplesse et sa facilité d’utilisation (commandes faciles à apprendre, documentation et communauté, repository distants gratuits en ligne…).

Enfin, une dernière solution est aussi de prendre un hébergement « haut de gamme » et spécialisé WordPress comme WPEngine. Pour 29$ / mois pour un site WordPress, vous disposerez d’une solution avec backup / restore et autre fonctionnalité de clonage dans un environnement optimisé et performant. C’est une question de choix et de budget.