Sviluppo locale con zinnector dev

zinnector dev esegue un vero WordPress sul Suo computer, servendo i plugin e i temi presenti nel Suo progetto, con la versione di PHP scelta da Lei. Questo articolo spiega i due runtime disponibili, come selezionare le versioni, cosa viene servito e da dove, e dove risiede il runtime sul disco — affinché ciò che testa localmente corrisponda a ciò che distribuisce.

I due runtime e perché sono entrambi reali

Playground è l'opzione predefinita. WordPress Playground compila PHP in WebAssembly e lo esegue all'interno di Node, consentendo a un portatile sul quale è installato solo Node di avviare un'istanza di WordPress in pochi secondi. È disponibile qualsiasi versione di PHP da 5.2 a 8.5. Include un set ridotto di estensioni PHP (intl, redis, memcached in base alla build attuale), sufficiente per la maggior parte delle attività su temi e plugin.

Docker esegue container nativi php-fpm e MariaDB. È più lento, richiede il daemon Docker e circa 1,2 GB di immagini, e supporta PHP da 7.4 a 8.5 — tuttavia esegue un PHP nativo con il set completo di estensioni, comprese imagick e gd. Rappresenta la soluzione ideale quando occorre testare un'estensione non inclusa nella build WebAssembly.

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

Non viene mai eseguito un fallback silenzioso a Docker. Uno sviluppatore convinto di utilizzare WebAssembly che si trovi invece su Docker riceverebbe una risposta errata da uno strumento che cerca di essere d'aiuto; per questo motivo è necessario richiederlo esplicitamente per nome.

Scelta delle versioni di PHP e WordPress

zinnector dev --php 8.1 --wp 6.7    # sviluppo con una coppia specifica
zinnector dev --port 9401           # quando la porta 9400 è occupata
zinnector dev --no-login            # non esegue l'accesso automatico a wp-admin
zinnector dev --verbose             # mostra l'output del runtime

I valori predefiniti provengono da zinnector.json all'interno del progetto — php, wordpress, runtime e port — generati da zinnector new e da sottoporre a commit, in modo che chiunque lavori al progetto utilizzi le medesime versioni. Un flag inserito da riga di comando ha la priorità sul file per la singola esecuzione.

La versione che si dichiara e quella che viene eseguita sono due dati differenti. zinnector dev --once avvia il runtime, mostra le informazioni effettivamente rilevate — versione di PHP, versione di WordPress, estensioni caricate — e si arresta. zinnector check --probe impiega la stessa rilevazione per confrontare il Suo progetto con uno slot di hosting.

Cosa viene servito dal Suo progetto

Il runtime monta direttamente le directory wp-content/plugins, wp-content/themes e wp-content/mu-plugins del Suo progetto, rendendo immediatamente visibile qualsiasi file salvato al successivo caricamento della pagina. Le directory esistenti che non contengono file reali non vengono volutamente montate: una directory themes/ vuota montata sui temi nativi del runtime lascerebbe WordPress completamente privo di temi, generando un errore 500 vuoto invece del Suo sito. Per questo motivo lo scaffold mantiene le cartelle vuote con un file .gitkeep, evitando che oscurino alcunché fino all'aggiunta di un tema al loro interno.

Dove risiede il runtime

Il runtime di WordPress viene scaricato al primo utilizzo anziché essere distribuito con la CLI — il pacchetto contenente tutte le build di PHP occupa circa 570 MB, e uno sviluppatore che deve soltanto elencare i siti non dovrebbe farsi carico di questo download. Viene archiviato nella cache proprietaria di Zinnector®, all'interno di ~/.cache/zinnector/runtimes/playground/<version> (o nel percorso specificato da ZINNECTOR_CACHE_DIR), mai all'interno del Suo progetto, impedendone l'inclusione nel repository o nella struttura rilevata da zinnector push. Il download viene eseguito dalla Sua installazione locale di npm, avviata come node npm-cli.js — mai tramite una shell.

La versione del runtime è vincolata a quella della CLI, garantendo che sviluppatori diversi sullo stesso progetto utilizzino le stesse build di PHP. Il comando zinnector dev --reset-runtime elimina il runtime installato e lo reinstalla da capo, risolvendo eventuali problemi di un runtime installato ma non avviabile.

Su Node 26 o versioni successive

La CLI è compatibile con qualsiasi versione di Node dalla 24 in poi. Tuttavia, il modulo nativo del runtime fornisce binari precompilati solo per Node 24 e 25 (a partire da settembre 2026). Per evitare processi di compilazione — che su Windows richiederebbero l'installazione di Visual Studio — Zinnector® scarica nella stessa cache un'istanza dedicata di Node 24 solo per il runtime, di circa 30 MB, verificata tramite i checksum pubblicati da nodejs.org. L'avviso di installazione lo notifica quando applicabile. Nessun aspetto della Sua installazione di Node viene modificato.

Contenuti correlati

• Per iniziare · Distribuzione · Guida ai comandi · Risoluzione dei problemi