How to: work across several sites

Looking after more than a handful of sites changes what you need. Not a faster way to do one thing on one site — a way to do the same thing on forty, and know which ones worked.

Every CLI command runs against one site, a named site, or all of them. That is the whole idea, and the rest of this page is what it makes possible.

One name per site

Each site you connect is saved as a profile, named after its address unless you say otherwise.

nibwp auth login https://client-one.com --name client-one
nibwp auth login https://staging.client-one.com --name staging

nibwp auth list        # every site, and what each connection may do
nibwp auth use staging # the default when you do not say

One command, every site

nibwp --all doctor
nibwp --all run nibwp/find-tools --input '{"query":"pending updates"}'
nibwp --site client-one discover "fix the contact form"

A run against many sites does not stop at the first failure. Each site is reported under its own heading, and the command finishes with a count — so one unreachable site never hides the answer for the other thirty-nine. The exit code is non-zero if any site failed, which is what you want in a scheduled job.

Edit a theme in your own editor

Pull a folder down, work on it with the tools you already use, and send back only what changed.

nibwp pull wp-content/themes/acme ./acme
# …edit locally…
nibwp push ./acme --dry-run
nibwp push ./acme

The pull records what it fetched. When you push, every file you changed is checked against the site first, and the whole run is refused if anything moved there while you were working — with the conflicting files named. A file you deleted locally is reported but never deleted on the site, because a missing file is far more often a partial checkout than an instruction.

• Scoped — it moves through the same approved connection as everything else, not an FTP account.
• Logged — every file written appears in the site’s Audit Log.
• Revocable — take the connection away and the access goes with it.

Reading files works on any plan. Writing them is a Pro ability, and the CLI tells you that before you start editing rather than after.

Do it once, repeat it everywhere

This is the one that changes how a workday looks. Your site records every call an assistant makes. The CLI can turn a run of those calls into a tape and carry out the same sequence somewhere else — no assistant involved the second time, and no variation.

# an assistant just built something on staging
nibwp --site staging tape pull --since 45m -o hero.tape.json

nibwp tape vars hero.tape.json          # anything that differs per site
nibwp replay hero.tape.json --all --dry-run
nibwp replay hero.tape.json --all

Three things it refuses to do, on purpose:

• It will not carry the wrong address — the site the tape came from is turned into a placeholder and filled from the site it is replayed onto, so a staging URL cannot land in production.
• It will not guess — anything else that differs between sites has to be supplied with --var name=value. A tape with an unfilled value stops rather than inventing one.
• It will not run code quietly — a tape containing PHP execution refuses unless you pass --allow-code.

A step that fails stops that site’s run, because step seven usually assumes step six happened. Add --continue if you would rather it pressed on.

Put things back

nibwp snapshot create --post-type page --options etch_styles -o before.json
# …let an assistant work…
nibwp snapshot restore before.json

Make an agent understand the site

nibwp init

Writes an AGENTS.md into the folder you are in, describing that site: which builder it runs, which skills are unlocked, what abilities exist, and the rules for working with it. Any assistant opening that project reads it and starts informed. Run it again after the site changes and anything you wrote yourself is left alone.

FAQ