Développement local avec zinnector dev

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 que vous choisissez. Cet article explique les deux environnements d’exécution qu’il peut utiliser, comment choisir les versions, ce qui est servi depuis quel emplacement, et où l’environnement d’exécution réside sur le disque — afin que ce que vous testez localement corresponde à ce que vous déployez.

Les deux environnements d’exécution, et pourquoi tous deux sont authentiques

Playground est l’option par défaut. WordPress Playground compile PHP en WebAssembly et l’exécute au sein de Node, de sorte qu’un ordinateur portable ne disposant que de Node installé démarre un WordPress en quelques secondes. Toute version de PHP comprise entre 5.2 et 8.5 est disponible. Il intègre un ensemble restreint d’extensions PHP (intl, redis, memcached tel que mesuré sur la version actuelle), ce qui est suffisant pour la plupart des travaux sur les extensions et 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 7.4 à 8.5 — mais il exécute un PHP natif doté de l’ensemble complet d’extensions, notamment imagick et gd. C’est la réponse adéquate lorsque ce que vous devez tester est une extension que la version WebAssembly n’embarque pas.

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

Docker n’est jamais utilisé comme solution de repli silencieuse. Un développeur qui pense être sur WebAssembly et se retrouve en réalité sur Docker a reçu une mauvaise réponse de la part d’un outil essayant d’aider, il doit donc être demandé explicitement par son nom.

Choisir les 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 la sortie propre à l'environnement d'exécution

Les valeurs par défaut proviennent du fichier zinnector.json du projet — php, wordpress, runtime et port — que zinnector new génère et que vous devriez commiter, afin que tous les intervenants sur le projet exécutent les mêmes versions. Une option sur la ligne de commande prévaut sur le fichier pour cette exécution.

La version que vous déclarez et celle qui s’exécute sont deux réalités distinctes. 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 — et s’arrête. zinnector check --probe utilise la même mesure lorsqu’il compare votre projet à un emplacement 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, de sorte qu’un fichier que vous enregistrez est actif dès le rechargement suivant. Les répertoires qui existent mais ne contiennent aucun contenu réel ne sont délibérément pas montés : un dossier themes/ vide monté par-dessus les thèmes propres à l’environnement d’exécution laisserait WordPress sans aucun thème, ce qui résulterait en une erreur 500 vide plutôt qu’en votre site. C’est pourquoi la structure de base conserve des répertoires vides avec un fichier .gitkeep et pourquoi ils ne masquent rien tant que vous n’y placez pas de thème.

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

L’environnement d’exécution de WordPress est téléchargé lors de la première utilisation plutôt que fourni avec l’interface en ligne de commande — le paquet qui contient chaque version de PHP pèse environ 570 Mo, et un développeur qui ne fait que lister des sites ne devrait pas avoir à le télécharger. Il est conservé dans le cache propre à Zinnector®, ~/.cache/zinnector/runtimes/playground/<version> (ou à l’emplacement indiqué par ZINNECTOR_CACHE_DIR), jamais dans votre projet, de sorte qu’il ne peut pas se retrouver dans votre dépôt ni dans l’arborescence que zinnector push mesure. Le téléchargement est effectué par votre propre npm, exécuté sous la forme node npm-cli.js — jamais via un interpréteur de commandes.

La version de l’environnement d’exécution est indexée sur celle de l’interface en ligne de commande, de sorte que deux développeurs 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 le réinstalle, ce qui résout le cas d’un environnement d’exécution installé mais qui refuse de démarrer.

Sur Node 26 ou version ultérieure

L’interface en ligne de commande s’exécute elle-même sur n’importe quelle version de Node à partir de la 24. Le module natif de l’environnement d’exécution, en revanche, ne fournit des binaires précompilés que pour Node 24 et 25 (en date de septembre 2026). Plutôt que de compiler quoi que ce soit — ce qui sous Windows implique d’installer Visual Studio —, Zinnector® télécharge dans le même cache un Node 24 réservé au seul environnement d’exécution, d’environ 30 Mo, vérifié par rapport aux sommes de contrôle publiées par nodejs.org. L’invite d’installation l’indique lorsque la situation se présente. Rien ne change concernant votre propre Node.

Voir aussi

• Prise en main · Déploiement · Référence des commandes · Dépannage