Un site de développement (dev, miroir, preprod…) permet de tester les mises à jour de WordPress et de ses extensions avant de les appliquer au site de production.
Les mises à jour de WordPress sont primordiales si l’on veut se protéger des piratages, profiter de nouvelles fonctionnalités et des corrections de bogues. La mise à jour de WordPress concerne le cœur de WordPress ainsi que le thème et les extensions (plugins).
En général les mises à jour se passent sans problème, mais il arrive un jour où ça coince, ça plante, c’est la cata. On se trouve alors face à un problème comme l’affichage perturbé, une fonctionnalité inopérante, ou carrément la terrible page blanche.
Bien sûr comme vous faites des sauvegardes, il vous sera possible de revenir en arrière. Mais cela prend du temps… Vous faites des sauvegardes, n’est-ce pas ?
Au moment ou j’écris cet article, WordPress 5 vient d’être publié. Cette mise à jour suscite beaucoup d’inquiétudes liées à l’impact du nouvel éditeur Gutenberg. Il est donc capital de faire un test de mise à jour avant de passer à la nouvelle version.
Accessoirement, le site de dev joue un rôle de « bac à sable » qui permet aux utilisateurs novices de tester leur actions en toute sécurité. C’est une pratique que je recommande à mes clients qui débutent avec WordPress.
Qu’est-ce qu’un site de développement ?
Un site de développement (dev) est une réplique du site de production. En général il existe avant le site de production. En effet, avant qu’un site Web soit en ligne, c’est-à-dire « en production », il passe par une phase de développement (dev).
Il est possible que le site de dev ait été supprimé après le passage du site en production, que le site ait été directement développer en production (ça arrive), ou que le prestataire qui a développé le site n’ait pas fourni de dev.
Comment mettre en place un site de dev ?
Voyons comment mettre en place un site de dev pour WordPress. Il existe deux types de sites, en ligne ou local.
Site de dev local
Le site de développement local est placé sur un ordinateur ou un serveur interne (non accessible depuis Internet) appartenant à l’entité (indépendant, agence…) qui développe le site.
Cette option nécessite une infrastructure applicative permettant de simuler un serveur Web tel qu’il fonctionne sur Internet.
Pour l’installation sur ordinateur personnel, il existe des solutions comme Lamp (pour Linux), Mamp (pour Mac) et Wamp (pour Windows). Elles simplifient la tâche en réunissant les logiciels nécessaires (serveur Web, base de données, interpréteur PHP) dans un paquet avec une interface de gestion de l’ensemble.
Site de dev en ligne
Pour un développement en ligne il faut disposer d’un hébergement de sites Web. Celui du site de production ou un autre.
Comment choisir entre un site local ou en ligne ?
Les deux solutions ont leurs avantages et leurs inconvénients.
Local | En ligne | |
Rapidité (accès, serveur, BdD) | + | – |
Sauvegardes | Dépendent de vous | Gérées par l’hébergeur |
Accessible en déplacement | Non | Oui |
Condition identiques à la production | Non | Oui |
Dépannage de l’infrastructure | Dépend de vous | Assuré par l’hébergeur |
Gestion des certificats SSL (HTTPS) | Non | Oui (Let’s Encrypt par ex.) |
Liberté de configuration | Oui | Non |
Choix version PHP et modules | Oui + | Oui |
Pour un site de taille modeste (fonctionnalités de base), le développement en ligne est le solution la plus pratique. À cela deux raisons :
- Comme la configuration est identique au site de production, le risque d’une différence de comportement après les mises à jour entre le dev et la prod est quasi nul.
- Pendant le développement l’accès au site de dev par un tiers (prestataire, client…) est plus simple.
Mise en place d’un site de dev en ligne
Pour la mise en place d’un site de dev local je vous renvoie à la lecture de la documentation qui accompagne les différentes plateformes (Lamp, Mamp, Wamp).
Le site de dev en ligne sera un clone du site de production.
La condition première est de disposer d’un hébergement Web. Il faudra aussi que votre hébergement accepte l’installation de plusieurs sites. En effet, le site de dev en ligne va occuper le même espace et les mêmes ressources (disque, base de données, mémoire) que le site de production.
Il faudra disposer d’une base de données et d’un répertoire dédié aux fichiers du site de dev. Bien qu’il soit techniquement possible d’utiliser une même base de donnée pour plusieurs sites, cela présente beaucoup de risques de perte de données et l’outil (Duplicator) utilisé pour la migration écrasera toutes les données de la base.
Si vous avez choisi un hébergeur de qualité (je vous recommande o2switch) celui-ci mettra à disposition une interface de gestion de votre hébergement de type Cpanel qui facilite grandement les manipulations suivantes.
Voici les étapes :
- Créer un sous domaine nommé « dev »
- Créer une base de donnée dédiée au dev
- Placer les fichiers de WordPress dans le dossier « dev »
- Installer le site en visant la base de données créé pour « dev »
Créer un sous-domaine
La création d’un sous-domaine est gratuite. L’opération est relativement simple avec le Cpanel. Il suffit de choisir le nom, par exemple « dev ». L’adresse du site de dev sera alors https://dev.example.com (example.com remplace ici votre nom de domaine).
L’interface du Cpanel vous proposera de créer le répertoire racine (c’est lui qui contient les fichiers de WordPress). Par défaut ce sera dev.example.com. Je vous conseille plutôt une arborescence inversée du type /example.com/dev. Vous pourrez, au besoin, placer d’autres site de dev dans example.com (dev2, etc.).
Si votre site de production est en HTTPS, n’oubliez pas de créer un certificat SSL pour le site de dev. Là aussi, le Cpanel fournit ce qu’il faut.
Créer une base de donnée dédiée au dev
Le site de dev va avoir besoin d’une base de donnée dédiée. C’est pourquoi il est important de choisir un hébergeur qui permette de disposer de plusieurs bases de données. (Chez o2switch il n’y a pas de limite au nombre de bases de données.)
Là aussi le Cpanel vous guide dans la création de la base. Veillez à lui attribuer un nom facilement identifiable et différent de celui de la base de données du site en production. Même conseil pour le nom de l’utilisateur de la base. Notez bien le mot de passe de l’utilisateur, vous en aurez besoin.
Dupliquer WordPress
Duplicator est l’extension parfaite pour créer un clone de site WordPress. Je vous recommande cet article sur l’utilisation détaillée de Duplicator.
Duplicator génère les fichiers date_nom-site_[identifiant]_archive.zip et date_nom-site_[identifiant]_installer.php.
- Déplacez les deux fichiers dans le dossier « dev »
- Ouvrez un navigateur sur l’URL https://dev.example.com. (Notez le httpS pour réaliser l’installation du dev en HTTPS.)
- Lancez l’installation en cliquant sur date_nom-site_[identifiant]_installer.php. Il faudra fournir le nom du serveur (localhost chez o2switch) de la base de données, l’utilisateur et le mot de passe.
Attention au contenu dupliqué !
Veillez à ce que le site de dev ne soit pas indexé par les moteurs de recherche. Cela parasiterait le site de production avec du contenu dupliqué.
Pour cela, dans Réglages > Lecture, cochez la case « Demander aux moteurs de recherche de ne pas indexer ce site ».
Vous pouvez aussi bloquer l’accès au site de dev en le protégeant par un mot de passe. L’extension Password Protected remplit cette fonction.
En plus d’éloigner les robots d’indexation vous préserverez ainsi la confidentialité du site de développement.
Bonne pratique WordPress
La sécurité de votre site dépend des bonnes pratiques que vous mettez en œuvre avant qu’un incident intervienne. Faire les mises à jour régulièrement est assurément la plus importante.
Faire en sorte que cela se fasse sans risque en testant avant de mettre en production est un bon moyen d’éviter les montées d’adrénalines intempestives.