Sviluppo locale con zinnector dev

zinnector dev esegue un vero WordPress sul proprio computer, servendo i plugin e i temi del progetto, con una versione di PHP a scelta. Questo articolo spiega i due runtime che può utilizzare, come scegliere le versioni, cosa viene servito da dove e dove risiede il runtime su disco, in modo che ciò che si testa in locale corrisponda a ciò che si distribuisce.

I due runtime e perché sono entrambi reali

Playground è l'impostazione predefinita. WordPress Playground compila PHP in WebAssembly e lo esegue all'interno di Node, consentendo a un computer portatile senza altro installato se non Node di avviare un WordPress in pochi secondi. È disponibile qualsiasi versione di PHP da 5.2 a 8.5. Include un piccolo set di estensioni PHP (intl, redis, memcached come misurato nella build corrente), sufficiente per la maggior parte del lavoro su plugin e temi.

Docker esegue contenitori nativi php-fpm e MariaDB. È più lento, richiede un daemon Docker e circa 1,2 GB di immagini, e supporta PHP da 7.4 a 8.5, ma esegue un PHP nativo con il set completo di estensioni, incluse imagick e gd. È la risposta sincera quando ciò che si deve testare è un'estensione non inclusa nella build WebAssembly.

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

Non si passa mai a Docker in modo silenzioso. Uno sviluppatore che pensa di utilizzare WebAssembly e sta invece utilizzando Docker ha ricevuto una risposta errata da uno strumento che cercava di aiutare, pertanto deve essere richiesto esplicitamente per nome.

Scelta delle versioni di PHP e WordPress

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

I valori predefiniti provengono da zinnector.json nel progetto (php, wordpress, runtime e port), che zinnector new scrive e che si dovrebbe aggiungere al controllo versione, in modo che tutti i membri del progetto eseguano le stesse versioni. Un flag sulla riga di comando ha la precedenza sul file per quella specifica esecuzione.

La versione che si dichiara e la versione che viene eseguita sono due fatti distinti. zinnector dev --once avvia il runtime, stampa ciò che viene effettivamente rilevato (versione di PHP, versione di WordPress, estensioni caricate) e si arresta. zinnector check --probe utilizza la stessa misurazione quando confronta il progetto con uno slot di hosting.

Cosa viene servito dal progetto

Il runtime monta direttamente le directory wp-content/plugins, wp-content/themes e wp-content/mu-plugins del progetto, pertanto un file salvato risulta attivo al successivo ricaricamento. Le directory esistenti che non contengono alcun contenuto effettivo non vengono montate deliberatamente: un themes/ vuoto montato sopra i temi nativi del runtime lascerebbe WordPress completamente privo di temi, risultando in un errore 500 vuoto anziché nel proprio sito. Per questo motivo lo scaffolding mantiene le directory vuote con un file .gitkeep e queste non sovrascrivono nulla finché non vi si inserisce un tema.

Dove risiede il runtime

Il runtime di WordPress viene scaricato al primo utilizzo anziché essere incluso nel CLI: il pacchetto che contiene ogni build di PHP pesa circa 570 MB e uno sviluppatore che si limita a elencare i siti non dovrebbe pagarne il costo. Viene conservato nella cache di Zinnector®, in ~/.cache/zinnector/runtimes/playground/<version> (o dove punta ZINNECTOR_CACHE_DIR), mai all'interno del progetto, in modo che non possa finire nel repository o nell'albero analizzato da zinnector push. Il download viene eseguito dal proprio npm, avviato come node npm-cli.js, mai tramite una shell.

La versione del runtime è bloccata alla versione del CLI, garantendo che due sviluppatori sullo stesso progetto eseguano le stesse build di PHP. zinnector dev --reset-runtime elimina il runtime installato e lo reinstalla, rappresentando la soluzione per un runtime installato ma non avviabile.

Su Node 26 o versioni successive

Il CLI stesso viene eseguito su 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). Anziché compilare alcunché (operazione che su Windows richiede l'installazione di Visual Studio), Zinnector® recupera una versione di Node 24 esclusivamente per il runtime, pari a circa 30 MB, verificata tramite i checksum pubblicati da nodejs.org, posizionandola nella stessa cache. Il prompt di installazione lo segnala durante l'applicazione. La configurazione di Node sul proprio sistema rimane invariata.

Correlati

• Per iniziare · Distribuzione · Riferimento comandi · Risoluzione dei problemi