Локални развој са zinnector dev

zinnector dev runs a real WordPress on your own machine, serving the plugins and themes in your project, with a PHP version you choose. This article explains the two runtimes it can use, how to pick versions, what is served from where, and where the runtime lives on disk — so that what you test locally is what you deploy.

The two runtimes, and why both are real

Playground is the default. WordPress Playground compiles PHP to WebAssembly and runs it inside Node, so a laptop with nothing installed but Node boots a WordPress in seconds. Any PHP from 5.2 to 8.5 is available. It carries a small set of PHP extensions (intl, redis, memcached as measured on the current build), which is enough for most plugin and theme work.

Docker runs native php-fpm and MariaDB containers. It is slower, needs a Docker daemon and about 1.2 GB of images, and supports PHP 7.4 to 8.5 — but it runs a native PHP with the full extension set, including imagick and gd. It is the honest answer when what you need to test is an extension the WebAssembly build does not carry.

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

Docker is never fallen back to silently. A developer who thinks they are on WebAssembly and is actually on Docker has been given the wrong answer by a tool trying to help, so it has to be asked for by name.

Choosing PHP and WordPress versions

zinnector dev --php 8.1 --wp 6.7    # develop against a specific pair
zinnector dev --port 9401           # when 9400 is taken
zinnector dev --no-login            # do not sign in to wp-admin automatically
zinnector dev --verbose             # show the runtime's own output

The defaults come from zinnector.json in the project — php, wordpress, runtime and port — which zinnector new writes and which you should commit, so everyone on the project runs the same versions. A flag on the command line wins over the file for that run.

The version you declare and the version that runs are different facts. zinnector dev --once boots the runtime, prints what it actually reports — PHP version, WordPress version, loaded extensions — and stops. zinnector check --probe uses the same measurement when it compares your project against a hosting slot.

What is served from your project

The runtime mounts your project's wp-content/plugins, wp-content/themes and wp-content/mu-plugins directories directly, so a file you save is live on the next reload. Directories that exist but hold no real content are deliberately not mounted: an empty themes/ mounted over the runtime's own themes would leave WordPress with no theme at all, which is a blank 500 rather than your site. That is why the scaffold keeps empty directories with a .gitkeep and why they do not shadow anything until you put a theme in them.

Where the runtime lives

The WordPress runtime is downloaded on first use rather than shipped with the CLI — the package that carries every PHP build is about 570 MB, and a developer who only ever lists sites should not pay for it. It is kept in Zinnector®'s own cache, ~/.cache/zinnector/runtimes/playground/<version> (or wherever ZINNECTOR_CACHE_DIR points), never in your project, so it cannot end up in your repository or in the tree zinnector push measures. The download is done by your own npm, run as node npm-cli.js — never through a shell.

The runtime version is pinned to the CLI version, so two developers on one project run the same PHP builds. zinnector dev --reset-runtime throws the installed runtime away and installs it again, which is the fix for a runtime that installed but will not boot.

On Node 26 or newer

The CLI itself runs on any Node from 24 up. The runtime's native module, however, ships prebuilt binaries only for Node 24 and 25 (as of September 2026). Rather than compile anything — which on Windows means installing Visual Studio — Zinnector® fetches a Node 24 for the runtime alone, about 30 MB, verified against the checksums nodejs.org publishes, into the same cache. The install prompt says so when it applies. Nothing about your own Node changes.

Related

• Getting started · Deploying · Command reference · Troubleshooting