Le site commence sa vie sur la machine du développeur et, quand il est mature, doit quitter le nid familial pour aller s’épanouir sur son serveur de prod. Explorons de plus près ce cycle de vie.

Environnement de dev

Nous l’avons rapidement mentionné dans le chapitre précédent, il existe une multitude de manière de faire tourner WordPress en local :

• Les environnements intégrés qui fournissent tous la stack LAMP ;
• L’environnement local natif, vous utilisez les paquets Apache, MySQL et PHP sur votre Linux, WSL ou macOS ;
• Le serveur de développement PHP intégré.

Il existe même d’autres solution clefs en main qui facilitent le cycle de vie en permettant de migrer le projet vers son hébergement avec des serveurs de prod et staging en un clic, nous allons voir cela plus en détails.

Certains – dont je fais partie – préfèrent avoir une stack native. Cela dépendra un peu de votre système d’exploitation mais de nos jours, Linux, macOS et Windows (grace au WSL) permettent tous d’avoir MySQL (ou MariaDB), PHP et Apache en natif.

La LAMP native

Apache (ou tout autre serveur HTTP) n’est pas obligatoire pour le dev dans la mesure où PHP offre un serveur de dev, démarrable d’un simple php -S localhost:PORT. Avec la wp-cli, on peut lancer d’un simple wp-cli server, easy !

Il ne reste dès lors plus qu’à installer MySQL. Il existe des binaires pour la plupart des système et l’ensemble des package managers proposent MySQL en standard.

Le all inclusive

Pour le dev, chacun a sa manière de faire les choses. Il y a évidemment les incontournables XAMPP, MAMP, et Wamp pour les environnements LAMP les plus connus. Ils incluent Apache (parfois aussi NGINX), PHP et MySQL (ou Maria) dans un simple package avec une belle GUI.

Dans la même veine, pour ceux qui craignent un peu la ligne de commande, il existe des outils similaires dédiés à WordPress. DevKinsta fournit tous les outils nécessaires au développement WordPress. De l’install en un click en passant par la sélection de la version de PHP au serveur SMTP, tout y est.

Il existe également localWP qui fournit dans l’ensemble les mêmes fonctions.

L’install

En local, l’installation dépendra forcément un peu de la méthode adoptée. Avec ma stack native, en utilisant Steroids, il n’y a qu’à créer une base de données et exécuter startserver.sh. Vous devriez bénéficier d’une simplicité équivalente avec les autres techniques.

Veillez cependant à prendre en compte le fait qu’avec Steroids et certains frameworks, la racine du serveur web n’est pas celle du projet mais public/. C’est à prendre en compte lorsque vous paramétrez les serveurs.

Si vous utilisez DevKinsta, soit vous optez pour une configuration manuelle, auquel cas, la procédure est la même, soit vous partez sur l’installation en un click, et là vous n’avez potentiellement rien à faire.

Dans le prochain chapitre, nous allons voir comment efficacement sécuriser un site WordPress.