Lokale Entwicklung mit zinnector dev

zinnector dev führt ein echtes WordPress auf Ihrem eigenen Rechner aus, das die Plugins und Themes in Ihrem Projekt bereitstellt, mit einer PHP-Version Ihrer Wahl. Dieser Artikel erklärt die beiden Laufzeiten, die es verwenden kann, wie Sie Versionen auswählen, was von wo bereitgestellt wird und wo die Laufzeit auf der Festplatte liegt – damit das, was Sie lokal testen, auch das ist, was Sie bereitstellen.

Die beiden Laufzeiten und warum beide echt sind

Playground ist die Standardeinstellung. WordPress Playground kompiliert PHP zu WebAssembly und führt es in Node aus, sodass ein Laptop, auf dem nur Node installiert ist, WordPress in Sekunden startet. Jedes PHP von 5.2 bis 8.5 ist verfügbar. Es enthält einen kleinen Satz von PHP-Erweiterungen (intl, redis, memcached gemessen am aktuellen Build), was für die meiste Plugin- und Theme-Arbeit ausreicht.

Docker führt native php-fpm- und MariaDB-Container aus. Es ist langsamer, benötigt einen Docker-Daemon und 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 ehrliche Antwort, wenn Sie eine Erweiterung testen müssen, die der WebAssembly-Build nicht enthält.

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

Es wird niemals stillschweigend auf Docker zurückgegriffen. Ein Entwickler, der denkt, er befind sich auf WebAssembly, sich aber tatsächlich auf Docker befindet, hat von einem Werkzeug, das helfen möchte, die falsche Antwort erhalten, weshalb es namentlich angefordert werden muss.

Auswählen von PHP- und WordPress-Versionen

zinnector dev --php 8.1 --wp 6.7    # Entwicklung gegen ein spezifisches Paar
zinnector dev --port 9401           # wenn 9400 belegt ist
zinnector dev --no-login            # nicht automatisch bei wp-admin anmelden
zinnector dev --verbose             # die eigene Ausgabe der Laufzeit anzeigen

Die Standardwerte stammen aus zinnector.json im Projekt – php, wordpress, runtime und port –, die von zinnector new geschrieben werden und die Sie einchecken sollten, damit jeder im Projekt dieselben Versionen ausführt. Ein Flag in der Befehlszeile hat für diesen Lauf Vorrang vor der Datei.

Die Version, die Sie deklarieren, und die Version, die läuft, sind unterschiedliche Tatsachen. zinnector dev --once startet die Laufzeit, gibt aus, was sie tatsächlich meldet – PHP-Version, WordPress-Version, geladene Erweiterungen – und stoppt. zinnector check --probe verwendet dieselbe Messung, wenn es Ihr Projekt mit einem Hosting-Slot vergleicht.

Was aus Ihrem Projekt bereitgestellt wird

Die Laufzeit 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 live ist. Verzeichnisse, die existieren, aber keinen echten Inhalt enthalten, werden bewusst nicht eingebunden: Ein leeres themes/, das über den eigenen Themes der Laufzeit eingebunden ist, würde WordPress ohne jegliches Theme zurücklassen, was einem leeren 500-Fehler anstelle Ihrer Website entspricht. Aus diesem Grund behält das Gerüst leere Verzeichnisse mit einer .gitkeep bei und verdeckt nichts, bis Sie ein Theme darin ablegen.

Wo die Laufzeit lebt

Die WordPress-Laufzeit wird bei der ersten Verwendung heruntergeladen, anstatt mit dem CLI ausgeliefert zu werden – das Paket, das jeden PHP-Build enthält, ist etwa 570 MB groß, und ein Entwickler, der nur Websites auflistet, sollte nicht dafür bezahlen. Sie wird im eigenen Cache von Zinnector® aufbewahrt, ~/.cache/zinnector/runtimes/playground/<version> (oder wo immer ZINNECTOR_CACHE_DIR hinweist), niemals in Ihrem Projekt, sodass sie nicht in Ihrem Repository oder in dem Baum landen kann, den zinnector push misst. Der Download erfolgt über Ihr eigenes npm, ausgeführt als node npm-cli.js – niemals über eine Shell.

Die Laufzeitversion ist an die CLI-Version geknüpft, sodass zwei Entwickler an einem Projekt dieselben PHP-Builds ausführen. zinnector dev --reset-runtime wirft die installierte Laufzeit weg und installiert sie erneut, was die Lösung für eine Laufzeit ist, die installiert wurde, aber nicht booten will.

Unter Node 26 oder neuer

Das CLI selbst läuft auf jedem Node ab Version 24. Das native Modul der Laufzeit liefert jedoch nur vorab erbaute Binärdateien für Node 24 und 25 (Stand: September 2026). Anstatt etwas zu kompilieren – was unter Windows die Installation von Visual Studio bedeutet –, ruft Zinnector® ein Node 24 nur für die Laufzeit ab, ca. 30 MB, verifiziert gegen die von nodejs.org veröffentlichten Prüfsummen, im selben Cache. Die Installationsaufforderung weist beim Anwenden darauf hin. An Ihrem eigenen Node ändert sich nichts.

Verwandt

• Erste Schritte · Bereitstellung · Befehlsreferenz · Fehlerbehebung