Ca sort du four!!

Lorsque l’on veut industrialiser le process de création de sites, il est nécessaire d’établir des procédures que l’on répète de manière similaire, sinon identiques à chaque nouveau projet. Je vous propose aujourd’hui notre procédure de synchronisation maison. Ne vous brûler pas, c’est tout chaud, ça sort à peine du four!!

Un développement de site se fait toujours en local, c’est à dire sur un poste client. Une fois les développements terminés, ou en cours de finalisation, il reste à uploader le contenu de son site sur son serveur distant. Cette tâche se compose de 2 parties distinctes :

• la copie des fichiers statiques :
  • core de wordpress
  • répertoires de plugins spécifiques au projet (wp-content/*plugins/*)
  • répertoire de thème du projet (wp-content/themes/monThemeProjet)
• la copie de la base de donnée

Dans un monde parfait, une simple copie serait suffisante, wordpress détecterait que l’emplacement de l’installation a changé, et prendrai en compte ce changement. Mais dans la vrai vie, une procédure un peu plus compliquée s’impose.

Pré-requis :

• le poste client est un linux-like (distribution linux ou Mac)
• le serveur est également un linux-like (plus facile à trouver!)
• un répertoire projet créé sur le serveur
• On a fait le nécessaire pour se connecter au serveur distant sans mot de passe (comme expliqué ici)

Notre procédure se compose de 7 étapes :

1. En local, exécuter le script suivant qui va réaliser un rsync (synchronisation du répertoire projet avec le répertoire cible sur le serveur :

# ./deploy_local_wordpress_rsync.sh
#!/bin/bash
# Ce script doit être exécuté depuis le répertoire contenant l'installation de wordpress
USER="julien"
HOST="monsite.com"
PORT=
RSYNC=`which rsync`
PROJECT_NAME=nom_de_mon_projet ## eg: portail_client_X
VERSION=1
DEPLOY_DIR=/var/www/html/staging/$PROJECT_NAME/$VERSION

echo "Deploiement de $PROJECT_NAME vers $DEPLOY_DIR"
$RSYNC -avz -e ssh ./ $USER@$HOST DEPLOY_DIR --exclude-from=wordpress_exclude.rsync

avec wordpress_exclude.rsync (fichier regroupant les fichiers/répertoires à ne pas synchroniser) pouvant ressembler à :

desktop.ini
.DS_Store
/wp-config.php
/wp-content/gallery
/wp-content/themes/blamatic
/wp-content/themes/classic
/wp-content/themes/default
/wp-content/themes/delight
/wp-content/themes/medical-theme
/wp-content/themes/modularity-lite
/wp-content/themes/retrospective
/wp-content/themes/simpleblocks
/wp-content/themes/thematic
/wp-content/themes/whiteboard
/wp-content/plugins/flexi-pages-widget
/wp-content/plugins/nextgen-gallery
/wp-content/plugins/wp-shopping-cart
/wp-content/plugins/wp_date_fr
/wp-content/uploads/wpsc
/wp-content/uploads/js_cache
/wp-config.php.BAK

2. Sur le serveur modifier les droits du répertoire

   wp-content

   (utilisé pour l’upload de contenus – images, attachements, etc -) :

   chmod -R 777 wp-content

3. 

   Création de la base wordpress sur le serveur

   Sur le serveur, créer de la base de donnée. Sous phpMyAdmin par exemple.

   Donner un nom à votre base, ici wp_database, choisir l’interclassement utf8_general_ci si possible pour une meilleur gestion des caractères spéciaux.

4. Sur le serveur, modifier le fichier wp-config (situé à la racine de wordpress) pour que wordpress puisse se connecter à la nouvelle base (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST)
5. Envoyer au serveur un Dump de la base locale (un Dump est un export de la base, onglet exporter sous phpMyAdmin) par exemple avec la commande :

scp monDump.sql user@serveur:repertoire

6. Importer le Dump dans la base du serveur (Onglet importer sous phpMyAdmin)
7. La base contient des chemins absolus correspondant à votre configuration locale : Mettez à jour tous les champs, via les commandes SQL suivantes :

UPDATE wp_options
SET option_value = replace(option_value, 'http://www.old-domain.com', 'http://www.new-domain.com')
WHERE option_name = 'home' OR option_name = 'siteurl';

UPDATE wp_posts
SET guid = replace(guid, 'http://www.old-domain.com','http://www.new-domain.com');

UPDATE wp_posts
SET post_content = replace(post_content, 'http://www.old-domain.com', 'http://www.new-domain.com');

TroubleShootings :
Attention au fichier .htaccess. Il semble que le fichier .htacess (utilisé pour gérer les Friendly URLs) se regénère automatiquement. Ce n’a pas été notre cas. Il a fallut éditer ce fichier pour le mettre à jour :
de l’ancienne version en local (on y accède via http://localhost/WPlocalInstall)

# BEGIN WordPress

RewriteEngine On
RewriteBase /WPlocalInstall/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /WPlocalInstall/index.php [L]

# END WordPress

à la nouvelle version sur le serveur :

# BEGIN WordPress

RewriteEngine On
#RewriteBase /localInstall/ ## COMMENTÉ CAR LE SITE EST À LA RACINE DU DOMAINE ##
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L] ## LE SITE EST À LA RACINE DU DOMAINE ##

# END WordPress

Bonne mise en ligne!!