Développement local avec zinnector dev

Comment zinnector dev exécute un véritable WordPress sur votre propre machine : les deux environnements d'exécution (WebAssembly sans Docker, ou PHP natif dans Docker), le choix d'une version de PHP et de WordPress, ce qui est servi depuis votre projet, où réside l'environnement d'exécution de 570 Mo, et ce qui se passe sur Node 26.

zinnector dev exécute un véritable WordPress sur votre propre machine, en servant les extensions et thèmes de votre projet avec la version de PHP de votre choix. Cet article explique les deux environnements d'exécution qu'il peut utiliser, la manière de choisir les versions, ce qui est servi depuis quel emplacement et où réside l'environnement d'exécution sur le disque — afin que ce que vous testiez en local corresponde à ce que vous déployez.

Les deux environnements d'exécution, et pourquoi ils sont tous les deux réels

Playground est l'option par défaut. WordPress Playground compile PHP en WebAssembly et l'exécute dans Node, si bien qu'un ordinateur portable ne disposant de rien d'autre que Node démarre un WordPress en quelques secondes. N'importe quelle version de PHP de 5.2 à 8.5 est disponible. Il embarque un petit ensemble d'extensions PHP (intl, redis, memcached mesurés sur la version actuelle), ce qui suffit pour la plupart des travaux sur les extensions et les thèmes.

Docker exécute des conteneurs natifs php-fpm et MariaDB. Il est plus lent, nécessite un démon Docker ainsi qu'environ 1,2 Go d'images, et prend en charge PHP de 7.4 à 8.5 — mais il exécute un PHP natif avec l'ensemble complet des extensions, y compris imagick et gd. C'est la réponse honnête lorsque ce que vous devez tester est une extension que la version WebAssembly ne possède pas.

zinnector dev                       # playground
zinnector dev --runtime docker      # PHP natif + MariaDB

Il n'y a jamais de basculement silencieux vers Docker. Un développeur qui pense être sur WebAssembly alors qu'il est en réalité sur Docker a reçu une fausse réponse d'un outil essayant d'aider ; l'environnement doit donc être demandé explicitement par son nom.

Choix des versions de PHP et de WordPress

zinnector dev --php 8.1 --wp 6.7    # développer avec une paire spécifique
zinnector dev --port 9401           # lorsque le port 9400 est occupé
zinnector dev --no-login            # ne pas se connecter automatiquement à wp-admin
zinnector dev --verbose             # afficher les propres sorties de l'environnement d'exécution

Les valeurs par défaut proviennent du fichier zinnector.json situé à la racine du projet — php, wordpress, runtime et port —, que zinnector new génère et que vous devriez valider dans votre gestionnaire de versions afin que l'ensemble des collaborateurs du projet exécutent les mêmes versions. Une option passée en ligne de commande l'emporte sur le fichier pour cette exécution.

La version que vous déclarez et la version qui s'exécute relèvent de faits différents. zinnector dev --once démarre l'environnement d'exécution, affiche ce qu'il rapporte réellement — version de PHP, version de WordPress, extensions chargées — puis s'arrête. zinnector check --probe utilise la même mesure lorsqu'il compare votre projet à un espace d'hébergement.

Ce qui est servi depuis votre projet

L'environnement d'exécution monte directement les répertoires wp-content/plugins, wp-content/themes et wp-content/mu-plugins de votre projet, si bien qu'un fichier enregistré est immédiatement actif au rechargement suivant. Les répertoires qui existent mais ne contiennent aucun contenu réel ne sont délibérément pas montés : un répertoire themes/ vide monté par-dessus les thèmes propres à l'environnement d'exécution laisserait WordPress sans aucun thème, ce qui produit une erreur 500 blanche plutôt que votre site. C'est la raison pour laquelle la structure de départ conserve les répertoires vides avec un fichier .gitkeep et pourquoi ils ne masquent rien tant que vous n'y placez pas un thème.

Où réside l'environnement d'exécution

L'environnement d'exécution WordPress est téléchargé lors de sa première utilisation plutôt que d'être fourni avec la CLI — le paquet contenant chaque version de PHP pèse environ 570 Mo, et un développeur qui se contente de lister des sites ne devrait pas avoir à le supporter. Il est conservé dans le propre cache de Zinnector®, à l'emplacement ~/.cache/zinnector/runtimes/playground/<version> (ou là où pointe ZINNECTOR_CACHE_DIR), et jamais dans votre projet, de sorte qu'il ne peut pas se retrouver dans votre dépôt ni dans l'arborescence analysée par zinnector push. Le téléchargement est effectué par votre propre instance de npm, exécutée en tant que node npm-cli.js — jamais par le biais d'un shell.

La version de l'environnement d'exécution est épinglée à celle de la CLI, de sorte que deux développeurs travaillant sur un même projet exécutent les mêmes versions de PHP. zinnector dev --reset-runtime supprime l'environnement d'exécution installé et l'installe à nouveau, ce qui constitue la solution en cas d'environnement installé mais récalcitrant au démarrage.

Sur Node 26 ou version ultérieure

La CLI elle-même s'exécute sur n'importe quelle version de Node à partir de la version 24. Le module natif de l'environnement d'exécution fournit toutefois des binaires précompilés uniquement pour Node 24 et 25 (à compter de septembre 2026). Plutôt que de compiler quoi que ce soit — ce qui, sous Windows, implique d'installer Visual Studio —, Zinnector® récupère un Node 24 destiné uniquement à l'environnement d'exécution, d'environ 30 Mo, vérifié par rapport aux sommes de contrôle publiées sur nodejs.org, et le place dans le même cache. L'invite d'installation l'indique lorsqu'elle s'applique. Rien ne change en ce qui concerne votre propre version de Node.