Почетак рада са Zinnector®, програмерским CLI-јем

Zinnector® is Zinn Digital®'s free, MIT-licensed command-line tool for WordPress developers. It scaffolds a site, runs a real WordPress on your own machine with nothing installed but Node — no Docker, no MAMP, no PHP on your PATH — then checks what you built against the hosting slot you are about to deploy to and pushes it. This guide takes you from nothing to a running site in about two minutes, and tells you what success looks like at every step so you know when something has gone wrong.

What you need

• Node 24 or newer. Run node --version; it must print v24 or higher. Install the current LTS from nodejs.org — on Windows winget install OpenJS.NodeJS.LTS, on macOS brew install node@24.
• npm, which comes with Node. Zinnector® uses it once, to download the WordPress runtime into its own cache.
• git, only for zinnector push — deploys are driven from your repository.
• Docker, only if you ask for it with --runtime docker. The default runtime needs none.

Nothing below needs an account. An API key is only needed when you reach a hosting slot, in Deploying with Zinnector®.

Step 1 — install it

npm install -g zinnector

If npm prints npm WARN EBADENGINE, your Node is older than the >=24.18.1 the package declares. The install finishes anyway, but the CLI will refuse to run. Upgrade Node first, then install again.

Step 2 — check the version

zinnector --version

Success: a version number, for example 0.1.2. If you see "Zinnector® needs Node 24 or newer — this is Node 20.x" the binary is installed but your Node is too old; the command exits with code 78 rather than doing anything.

Step 3 — read the help

zinnector --help

Success: a banner naming the five commands of the flow (new, dev, link, check, push) and then every command with a one-line purpose. Every command also takes --help of its own — zinnector dev --help lists the runtime, PHP and port flags. The complete list, with examples, is in the command reference.

Step 4 — scaffold a site

zinnector new my-site

Success: a Created my-site heading and a list of the files it wrote — zinnector.json, a wp-content tree with plugins/, themes/ and a mu-plugins/ helper, a .gitignore and a README — followed by the next commands to run. Nothing in it is a placeholder; the project boots as it is. --template plugin or --template theme scaffold a plugin or a block theme that activates the moment it exists.

Step 5 — run it

cd my-site
zinnector dev

The first time, Zinnector® asks once before downloading the WordPress runtime — about 570 MB, because it carries every PHP build from 5.2 to 8.5 — into its own cache directory, never into your project. Answer Y, or pass --yes to skip the question. On Node 26 or newer it also fetches a Node 24 for the runtime alone (about 30 MB, verified against nodejs.org's checksums), because the runtime's native module has prebuilt binaries only for Node 24 and 25; you do not need a compiler or Visual Studio.

Success: a block that names the project, the PHP version and the WordPress version, then:

✔ running at http://127.0.0.1:9400
  admin: http://127.0.0.1:9400/wp-admin  (already signed in)

Step 6 — open it

Visit http://127.0.0.1:9400 in a browser. Success: a fresh WordPress site titled My WordPress Website, served by the PHP version you asked for. http://127.0.0.1:9400/wp-admin opens the dashboard already signed in. Drop a plugin into wp-content/plugins/ or a theme into wp-content/themes/ and it is there on the next reload — the runtime serves those directories straight from your project.

Press Ctrl-C to stop. zinnector dev --once boots the runtime, prints what is actually running (PHP version, WordPress version, loaded extensions) and stops — useful when you want proof rather than a promise.

Where to go next

• Local development with zinnector dev — the two runtimes, choosing PHP and WordPress versions, and what is served from where.
• Deploying with Zinnector® — sign in, link the project to a slot, pre-flight it, push.
• The command reference — every command, flag and example.
• Troubleshooting — the errors people actually hit, and the fix for each.

The same documentation is in the package's README on npm and on GitHub, where issues and pull requests are welcome.