Base de connaissances
Les erreurs auxquelles les utilisateurs sont réellement confrontés avec l’interface CLI Zinnector® et la solution pour chacune d’elles : spawn EINVAL sous Windows, l’avertissement EBADENGINE de npm, node-gyp demandant Visual Studio sur Node 26, EPERM pendant l’installation, un environnement d’exécution qui ne démarre pas et un port déjà utilisé.
Les erreurs que les utilisateurs rencontrent réellement avec le CLI Zinnector®, la signification de chacune et la solution. Chaque entrée indique le texte exact que vous verrez, afin que vous puissiez le rechercher sur cette page. Si la vôtre ne s’y trouve pas, exécutez la commande qui échoue avec ZINNECTOR_DEBUG=1 et ouvrez un ticket sur github.com/Zinn-Digital/zinnector/issues avec la sortie générée, votre node --version et votre système d’exploitation.
Un bug présent dans Zinnector® 0.1.0 et 0.1.1. Sur Windows, le programme d’installation du runtime exécutait npm.cmd par son nom, et Node refuse de lancer un fichier .cmd sans shell depuis son correctif pour CVE-2024-27980 — l’installation plantait donc une seconde après avoir répondu O. Corrigé dans la version 0.1.2 : npm est désormais exécuté sous la forme node npm-cli.js, ce qui est identique sur toutes les plateformes et ne nécessite aucun shell. Exécutez npm install -g zinnector@latest, puis de nouveau zinnector dev.
Votre version de Node est antérieure à la version 24. npm affiche cet avertissement car le package déclare engines: >=24.18.1 ; l’installation se termine tout de même, mais zinnector refuse ensuite de démarrer (code de sortie 78) plutôt que d’échouer plus tard de manière confuse. Installez la version LTS actuelle depuis nodejs.org — winget install OpenJS.NodeJS.LTS sur Windows, brew install node@24 sur macOS — confirmez que node --version affiche v24 ou une version supérieure, puis installez de nouveau Zinnector®.
Le runtime WordPress possède un module natif dont les binaires précompilés n’existent que pour Node 24 et 25. Sur une version plus récente de Node (26 et plus, à compter de septembre 2026), son programme d’installation se rabat sur la compilation à partir des sources, ce qui aboutit sur une machine Windows standard à une demande d’installation de Visual Studio. Corrigé dans la version 0.1.2 : Zinnector® détecte cela avant de télécharger quoi que ce soit et récupère un Node 24 réservé au runtime — environ 30 Mo, vérifiés par rapport aux sommes de contrôle de nodejs.org — afin que rien ne soit jamais compilé. Si vous le constatez toujours après la mise à niveau, exécutez zinnector dev --reset-runtime afin que l’installation précédente inachevée soit d’abord supprimée.
Il s’agit presque toujours d’un antivirus ou d’un indexeur de recherche qui maintient un fichier ouvert sous le dossier node_modules du runtime pendant que npm tente de le supprimer. L’installation est réessayée à partir d’un répertoire propre lors du prochain zinnector dev ; si le problème persiste, zinnector dev --reset-runtime supprime d’abord l’intégralité du répertoire du runtime et procède à une nouvelle installation.
Le message inclut les dernières lignes générées par npm ainsi que la commande exacte exécutée par Zinnector®, afin que vous puissiez l’exécuter vous-même et voir la sortie complète. Les causes habituelles sont un problème de réseau ou de proxy — le runtime est récupéré avec votre propre npm, donc npm config set proxy … et un miroir de registre s’appliquent — ou une installation antérieure inachevée, ce que --reset-runtime résout.
Exécutez zinnector dev --verbose pour voir la sortie propre au runtime. Un port déjà utilisé est le cas le plus fréquent : zinnector dev --port 9401, ou définissez port dans zinnector.json. Un runtime qui s’est installé mais ne veut pas démarrer : zinnector dev --reset-runtime. Le premier démarrage télécharge également WordPress lui-même ; sur une connexion lente, patientez donc quelques minutes ; le CLI attend jusqu’à cinq minutes avant de signaler un délai d’attente dépassé plutôt que de se bloquer.
Les déploiements sont gérés à partir d’un dépôt, donc zinnector push en requiert un avec un distant accessible par la plateforme. git init && git add -A && git commit -m initial, ajoutez votre distant GitHub ou GitLab, puis zinnector link pour le connecter au site.
Exécutez zinnector check. Neuf fois sur dix, il s’agit d’un écart de version de PHP — vous avez développé sur un PHP plus récent que celui exécuté par l’emplacement — et le rapport indique vers quelle version basculer l’emplacement avec zinnector php <version>, ou avec laquelle développer à l’aide de zinnector dev --php <version>. zinnector logs --error affiche l’erreur fatale elle-même.
Ce que nous avons écrit sur l’hébergement, le SEO et la gestion de sites à grande échelle.
Comment l’hébergement façonne l’indexation et le jus de lien en 2026 : maintenir les pages indexées, évaluer les domaines expirés avant de les exploiter, créer des liens sans empreinte pour les moteurs de recherche, et un aperçu honnête de ce que l’infrastructure peut et ne peut pas faire pour le SEO.
Lire l’article →Une liste de contrôle pratique pour un WordPress rapide et sécurisé : mise en cache au niveau du serveur, cache d’objets par site, la poignée d’extensions utiles, maintien de la pile à jour et pages WooCommerce à ne jamais mettre en cache.
Lire l’article →Ce qui différencie réellement un bon hébergement infogéré d’une machine bon marché avec panneau de configuration — migrations, sauvegardes, isolation, véritable mise en cache et mise à l’échelle honnête — et comment en juger avant de vous engager.
Lire l’article →Le support est inclus dans chaque forfait, le service est ouvert 24 heures par jour et vous pouvez nous écrire dans l’une de nos 58 langues ; nous vous répondons dans la vôtre.
Contacter l’assistance → Tous les articles →