Lokale ontwikkeling met zinnector dev

zinnector dev draait een echte WordPress op uw eigen machine, die de plugins en thema's in uw project serveert, met een PHP-versie die u zelf kiest. Dit artikel legt de twee runtimes uit die het kan gebruiken, hoe u versies kiest, wat van waaruit wordt geserveerd en waar de runtime zich op de schijf bevindt — zodat wat u lokaal test overeenkomt met wat u implementeert.

De twee runtimes, en waarom beide echt zijn

Playground is de standaard. WordPress Playground compileert PHP naar WebAssembly en draait het binnen Node, waardoor een laptop waarop niets anders dan Node is geïnstalleerd binnen enkele seconden een WordPress opstart. Elke PHP-versie van 5.2 tot 8.5 is beschikbaar. Het bevat een kleine set PHP-extensies (intl, redis, memcached zoals gemeten op de huidige build), wat voldoende is voor het meeste werk aan plugins en thema's.

Docker draait native php-fpm- en MariaDB-containers. Het is langzamer, vereist een Docker-daemon en ongeveer 1,2 GB aan images, en ondersteunt PHP 7.4 tot 8.5 — maar het draait een native PHP met de volledige set extensies, inclusief imagick en gd. Het is het eerlijke antwoord wanneer u een extensie moet testen die de WebAssembly-build niet bevat.

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

Er wordt nooit stilzwijgend teruggevallen op Docker. Een ontwikkelaar die denkt dat hij op WebAssembly werkt en eigenlijk op Docker zit, heeft het verkeerde antwoord gekregen van een tool die probeerde te helpen, dus het moet expliciet bij naam worden aangeroepen.

PHP- en WordPress-versies kiezen

zinnector dev --php 8.1 --wp 6.7    # ontwikkelen tegen een specifiek paar
zinnector dev --port 9401           # wanneer 9400 bezet is
zinnector dev --no-login            # niet automatisch aanmelden bij wp-admin
zinnector dev --verbose             # de eigen uitvoer van de runtime tonen

De standaardwaarden zijn afkomstig uit zinnector.json in het project — php, wordpress, runtime en port — wat door zinnector new wordt weggeschreven en wat u zou moeten committen, zodat iedereen binnen het project dezelfde versies draait. Een vlag op de opdrachtregel heeft voor die sessie voorrang op het bestand.

De versie die u declareert en de versie die draait, zijn verschillende feiten. zinnector dev --once start de runtime op, toont wat deze daadwerkelijk rapporteert — PHP-versie, WordPress-versie, geladen extensies — en stopt. zinnector check --probe gebruikt dezelfde meting wanneer het uw project vergelijkt met een hostingslot.

Wat er vanuit uw project wordt geserveerd

De runtime koppelt de mappen wp-content/plugins, wp-content/themes en wp-content/mu-plugins van uw project rechtstreeks, zodat een bestand dat u opslaat bij de volgende herlaadbeurt direct actief is. Mappen die wel bestaan maar geen echte inhoud bevatten, worden bewust niet gekoppeld: een lege map themes/ die over de eigen thema's van de runtime wordt gekoppeld, zou WordPress achterlaten zonder enig thema, wat resulteert in een blanco 500-fout in plaats van uw site. Daarom behoudt het scaffold lege mappen met een .gitkeep en overschrijven ze niets totdat u er een thema in plaatst.

Waar de runtime zich bevindt

De WordPress-runtime wordt gedownload bij het eerste gebruik in plaats van meegeleverd te worden met de CLI — het pakket dat elke PHP-build bevat is ongeveer 570 MB groot, en een ontwikkelaar die alleen sites opsomt hoeft daar niet voor te betalen. Het wordt bewaard in de eigen cache van Zinnector®, ~/.cache/zinnector/runtimes/playground/<version> (of waar ZINNECTOR_CACHE_DIR ook naar verwijst), nooit in uw project, zodat het niet in uw repository of in de door zinnector push gemeten boomstructuur terecht kan komen. De download wordt uitgevoerd door uw eigen npm, uitgevoerd als node npm-cli.js — nooit via een shell.

De runtimeversie is gekoppeld aan de CLI-versie, zodat twee ontwikkelaars op één project dezelfde PHP-builds draaien. zinnector dev --reset-runtime verwijdert de geïnstalleerde runtime en installeert deze opnieuw, wat de oplossing is voor een runtime die wel geïnstalleerd is maar niet wil opstarten.

Op Node 26 of nieuwer

De CLI zelf draait op elke Node-versie vanaf 24. De native module van de runtime levert echter alleen vooraf gecompileerde binaire bestanden voor Node 24 en 25 (vanaf september 2026). In plaats van iets te compileren — wat op Windows betekent dat Visual Studio moet worden geïnstalleerd — haalt Zinnector® alleen voor de runtime een Node 24 op (ongeveer 30 MB), geverifieerd aan de hand van de door nodejs.org gepubliceerde controlesommen, naar dezelfde cache. De installatieprompt geeft dit aan wanneer dit van toepassing is. Er verandert niets aan uw eigen Node.

Gerelateerd

• Aan de slag · Implementeren · Overzicht van opdrachten · Probleemoplossing