Le nouvel environnement de développement WordPress

Le développement de plugins / thèmes WordPress a longtemps été une activité artisanale à la limite de l’amateurisme, du do-it-yourself et de l’exercice pour étudiant développeur.

Les temps ont changé. WordPress est devenu au fil des années le CMS le plus utilisé, de très loin. En 2024, 43% des sites étaient construits avec WordPress. De grandes compagnies l’utilisent, pas seulement pour faire des sites vitrines, mais aussi des sites e-commerce.

Le problème

Le problème dans le développement pour WordPress, comme pour beaucoup de CMS, c’est la sanctuarisation du noyau. On ne touche pas au fichiers du « core » WordPress. Ce faisant, on risquerait un effacement de nos modifications lors de la première mise à jour.

On doit donc développer soir une extension, soit un thème. Ces extensions / Thèmes sont situés dans un sous-répertoire du système de fichier WordPress, le répertoire wp-content.

SI vous souhaitiez, il y a quelques années, développer un nouveau plugin, vous deviez donc créer un nouveau projet dans votre IDE, ce projet pointant vers une installation complète WordPress. Mais vous n’alliez modifier et versionner qu’une petite partie de cette installation. Le temps passant, votre installation locale de WordPress devenait obsolète (les mises à jour s’enchainant rapidement), et si vous y retourniez plusieurs années plus tard il vous fallait refaire l’installation ou la mise à jour en local. Idem pour les extensions dont votre extension sur-mesure dépendait éventuellement.

L’amélioration

Depuis quelques années la conteneurisation (avec Docker) est devenue une norme dans les environnements de développement. Pour résumer : il s’agit d’empaqueter dans un « conteneur » toutes les dépendances de votre projet : dépendances applicatives (ici, WordPress, un serveur linux, une base de données MySQL), permettant de « transporter » votre projet à peu près n’importe où du moment que la machine hôte exécute docker.

L’énorme pas en avant qu’a été le développement de l’éditeur Gutenberg a été l’occasion de moderniser l’environnement de développement; celui-ci fut nommé wp-env par les contributeurs du projet. Cet environnement permet de se focaliser uniquement sur votre projet (thème ou plugin) et de considérer WordPress comme une dépendance de votre projet.

Comment ça marche

La documentation WordPress est déjà très bien faite, et je vous en livre les grandes étapes :

Pré-requis

• Docker et / ou docker desktop
• git
• node
• être à l’aise avec la ligne de commande et l’architecture WordPress
• Disposer d’un IDE (Par exemple PHPStorm) – pas obligatoire mais tout sera mieux intégré.

Installation

Installation globale (permet de créer plusieurs projets avec le même outil) :

npm -g install @wordpress/env

Puis, dirigez-vous dans le répertoire de travail de votre nouveau projet et :

wp-env start

Ensuite vous pouvez vous rendre sur le site : http://localhost:8888/wp-admin. Vous pouvez saisir les mots de passe admin et password.

Pour ceux que cela terrorise d’utiliser ces identifiants, sachez que nous sommes dans un environnement de travail local, et ces identifiants ne vont pas quitter votre ordinateur. Sachez aussi que vous pouvez modifier ces identifiants, nous allons voir cela plus tard.

Quelques commandes

wp-env stop

Est-il besoin de préciser ce que cela fait ?

wp-env destroy

Utile lorsque vous êtes bloqué et que vous n’avez pas peur de perdre ce que vous avez enregistré dans la base de données locale.

Paramétrage

A la racine de votre projet, disposez un fichier nommé .wp-env.json. Vous pouvez y définir la version de WordPress sur laquelle vous souhaitez travailler, les extensions pré-installées, les thèmes pré-installés, les constantes que vous souhaitez ajouter au fichier wp-config.php, etc.