Lokale Entwicklung mit zinnector dev

zinnector dev führt ein echtes WordPress auf Ihrem eigenen Rechner aus, stellt die Plugins und Themes Ihres Projekts bereit und verwendet eine PHP-Version Ihrer Wahl. Dieser Artikel erklärt die beiden Laufzeitumgebungen, die dafür verwendet werden können, wie Sie Versionen auswählen, was von wo bereitgestellt wird und wo sich die Laufzeitumgebung auf der Festplatte befindet – damit das, was Sie lokal testen, auch dem entspricht, was Sie bereitstellen.

Die beiden Laufzeitumgebungen und warum beide echt sind

Playground ist der Standard. WordPress Playground kompiliert PHP zu WebAssembly und führt es innerhalb von Node aus, sodass ein Laptop, auf dem lediglich Node installiert ist, ein WordPress in Sekundenschnelle startet. Jedes PHP von 5.2 bis 8.5 ist verfügbar. Es enthält einen kleinen Satz von PHP-Erweiterungen (intl, redis, memcached im aktuellen Build), was für die meisten Plugin- und Theme-Arbeiten ausreicht.

Docker führt native php-fpm- und MariaDB-Container aus. Es ist langsamer, benötigt einen Docker-Daemon sowie etwa 1,2 GB an Images und unterstützt PHP 7.4 bis 8.5 – führt jedoch ein natives PHP mit dem vollständigen Erweiterungssatz aus, einschließlich imagick und gd. Es ist die passende Wahl, wenn Sie eine Erweiterung testen müssen, die im WebAssembly-Build nicht enthalten ist.

zinnector dev                       # Playground
zinnector dev --runtime docker      # natives PHP + MariaDB

Es wird niemals stillschweigend auf Docker zurückgegriffen. Ein Entwickler, der davon ausgeht, auf WebAssembly zu arbeiten, sich tatsächlich aber auf Docker befindet, hätte ein unerwünschtes Ergebnis von einem Tool erhalten, das lediglich helfen wollte. Daher muss Docker explizit angegeben werden.

PHP- und WordPress-Versionen auswählen

zinnector dev --php 8.1 --wp 6.7    # Entwicklung gegen eine bestimmte Kombination
zinnector dev --port 9401           # wenn 9400 belegt ist
zinnector dev --no-login            # nicht automatisch bei wp-admin anmelden
zinnector dev --verbose             # die Ausgabe der Laufzeitumgebung selbst anzeigen

Die Standardwerte stammen aus der Datei zinnector.json im Projekt – php, wordpress, runtime und port –, die von zinnector new erstellt wird und die Sie committen sollten, damit alle Beteiligten am Projekt dieselben Versionen verwenden. Ein Flag in der Befehlszeile hat für diesen Aufruf Vorrang vor der Datei.

Die Version, die Sie deklarieren, und die Version, die ausgeführt wird, sind zwei unterschiedliche Fakten. zinnector dev --once startet die Laufzeitumgebung, gibt aus, was diese tatsächlich meldet – PHP-Version, WordPress-Version, geladene Erweiterungen – und stoppt anschließend. zinnector check --probe verwendet denselben Abgleich, wenn es Ihr Projekt mit einem Hosting-Slot vergleicht.

Was aus Ihrem Projekt bereitgestellt wird

Die Laufzeitumgebung bindet die Verzeichnisse wp-content/plugins, wp-content/themes und wp-content/mu-plugins Ihres Projekts direkt ein, sodass eine von Ihnen gespeicherte Datei beim nächsten Neuladen sofort wirksam ist. Verzeichnisse, die zwar existieren, aber keine echten Inhalte enthalten, werden bewusst nicht eingebunden: Ein leeres Verzeichnis themes/, das über die Themes der Laufzeitumgebung eingebunden wird, würde dazu führen, dass WordPress über überhaupt kein Theme mehr verfügt – was einen leeren 500-Fehler anstelle Ihrer Website zur Folge hätte. Aus diesem Grund behält das Gerüst leere Verzeichnisse mit einer .gitkeep-Datei bei, und deshalb verdecken sie erst dann etwas, wenn Sie ein Theme darin ablegen.

Wo sich die Laufzeitumgebung befindet

Die WordPress-Laufzeitumgebung wird bei der ersten Nutzung heruntergeladen, anstatt mit dem CLI ausgeliefert zu werden – das Paket, das sämtliche PHP-Builds enthält, ist etwa 570 MB groß, und ein Entwickler, der lediglich Websites auflistet, sollte diesen Speicherplatz nicht aufwenden müssen. Sie wird im systemeigenen Cache von Zinnector® gespeichert, unter ~/.cache/zinnector/runtimes/playground/<version> (oder worauf ZINNECTOR_CACHE_DIR verweist), niemals in Ihrem Projekt. So kann sie weder in Ihrem Repository noch in dem von zinnector push erfassten Dateibaum landen. Der Download wird von Ihrem eigenen npm durchgeführt, ausgeführt als node npm-cli.js – niemals über eine Shell.

Die Version der Laufzeitumgebung ist an die CLI-Version gebunden, sodass zwei Entwickler desselben Projekts dieselben PHP-Builds ausführen. zinnector dev --reset-runtime verwirft die installierte Laufzeitumgebung und installiert sie erneut, was als Behebung für eine Laufzeitumgebung dient, die zwar installiert wurde, sich aber nicht starten lässt.

Unter Node 26 oder neuer

Das CLI selbst läuft auf jedem Node ab Version 24. Das native Modul der Laufzeitumgebung liefert jedoch (Stand September 2026) vorkompilierte Binärdateien nur für Node 24 und 25 aus. Anstatt etwas zu kompilieren – was unter Windows die Installation von Visual Studio bedeuten würde –, lädt Zinnector® ein etwa 30 MB großes Node 24 ausschließlich für die Laufzeitumgebung in denselben Cache herunter, geprüft anhand der von nodejs.org veröffentlichten Prüfsummen. Die Installationsabfrage weist darauf hin, wenn dies zutrifft. An Ihrer eigenen Node-Installation ändert sich dabei nichts.

Verwandte Themen

• Erste Schritte · Bereitstellung · Befehlsreferenz · Fehlerbehebung