Lokaal ontwikkelen met zinnector dev

zinnector dev laat een echte WordPress draaien op uw eigen machine, en serveert de plugins en thema's in uw project, met een PHP-versie naar keuze. Dit artikel behandelt de twee runtimes die kunnen worden gebruikt, hoe u versies kiest, wat er waar wordt geserveerd en waar de runtime zich op de schijf bevindt — zodat wat u lokaal test ook daadwerkelijk is wat u implementeert.

De twee runtimes, en waarom beide echt zijn

Playground is de standaard. WordPress Playground compileert PHP naar WebAssembly en voert dit uit binnen Node, waardoor een laptop waarop alleen Node is geïnstalleerd binnen enkele seconden een WordPress-installatie opstart. Elke PHP-versie van 5.2 tot 8.5 is beschikbaar. De tool bevat een kleine set PHP-extensies (intl, redis, memcached zoals gemeten bij de huidige build), wat voldoende is voor het meeste plugin- en themawerk.

Docker voert native php-fpm- en MariaDB-containers uit. Dit is langzamer, vereist een Docker-daemon en ongeveer 1,2 GB aan images, en ondersteunt PHP 7.4 tot 8.5 — maar het voert een native PHP uit met de volledige set extensies, inclusief imagick en gd. Dit is de juiste keuze wanneer u een extensie moet testen die niet aanwezig is in de WebAssembly-build.

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

Er wordt nooit stilzwijgend teruggevallen op Docker. Een ontwikkelaar die denkt dat hij WebAssembly gebruikt terwijl dit in werkelijkheid Docker is, krijgt een onjuist antwoord van een tool die probeert te helpen; daarom moet hier expliciet om worden gevraagd.

PHP- en WordPress-versies kiezen

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

De standaardwaarden zijn afkomstig uit zinnector.json in het project — php, wordpress, runtime en port — welke worden geschreven door zinnector new en die u dient toe te voegen aan uw versiebeheer, zodat iedereen binnen het project dezelfde versies gebruikt. Een vlag in de opdrachtregel heeft voor die specifieke uitvoering prioriteit over het bestand.

De versie die u declareert en de versie die draait, zijn verschillende feiten. zinnector dev --once start de runtime op, drukt af wat deze daadwerkelijk rapporteert — PHP-versie, WordPress-versie, geladen extensies — en stopt. zinnector check --probe gebruikt dezelfde meting bij het vergelijken van uw project met een hosting-slot.

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 direct, zodat een opgeslagen bestand direct actief is bij de volgende herlaadbeurt. Mappen die wel bestaan maar geen echte inhoud bevatten, worden bewust niet gekoppeld: een lege themes/-map die over de eigen thema's van de runtime heen wordt gekoppeld, zou ervoor zorgen dat WordPress helemaal geen thema meer heeft, wat resulteert in een lege 500-fout in plaats van uw website. Dit is de reden waarom de steiger lege mappen behoudt met een .gitkeep en waarom deze niets overschrijven totdat u er een thema in plaatst.

Waar de runtime zich bevindt

De WordPress-runtime wordt bij het eerste gebruik gedownload in plaats van meegeleverd met de CLI — het pakket dat elke PHP-build bevat is ongeveer 570 MB groot, en een ontwikkelaar die uitsluitend websites vermeldt hoeft hier niet voor te betalen. Het wordt bewaard in de eigen cache van Zinnector®, namelijk ~/.cache/zinnector/runtimes/playground/<version> (of waar ZINNECTOR_CACHE_DIR naar verwijst), en dus nooit in uw project zelf. Hierdoor kan het niet terechtkomen in uw repository of in de mappenstructuur die zinnector push analyseert. Het downloaden wordt uitgevoerd door uw eigen npm, aangeroepen als node npm-cli.js — en verloopt nooit via een shell.

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

Op Node 26 of hoger

De CLI zelf draait op elke Node-versie vanaf 24. De native module van de runtime levert echter vooraf gebouwde binaire bestanden op voor uitsluitend Node 24 en 25 (peildatum september 2026). In plaats van zaken te compileren — wat op Windows zou inhouden dat Visual Studio moet worden geïnstalleerd — haalt Zinnector® een Node 24 binnen voor uitsluitend de runtime (ongeveer 30 MB), waarvan de integriteit wordt geverifieerd aan de hand van de checksums die nodejs.org publiceert, en plaatst dit in dezelfde cache. De installatiemelding vermeldt dit wanneer deze wordt toegepast. Er verandert niets aan uw eigen Node-omgeving.

Gerelateerd

• Aan de slag · Implementeren · Opdrachtenreferentie · Probleemoplossing