cwp pull

cwp pull [env] [flags]

Acts on dev unless another environment is named.

Argument	What it is	Default
[env]	environment to pull from	dev

Flag	What it does	Default
--uploads <mode>	uploads strategy: sync | skip | proxy
--no-scrub	skip data scrubbing (the mail guard is still installed)	on
--no-snapshot	skip the local database snapshot taken before the import	on
--db-only	database only — no uploads	off
--uploads-only	uploads only — leave the database untouched	off
--yes	skip the confirmation prompt	off

Plus the shared flags --json, --verbose and --dry-run.

What it does

The workhorse. It brings an environment’s database and uploads down and does everything that has to happen to make a production dump safe and usable on your machine.

In order: confirm the local database will be replaced → snapshot the local database → remote wp db export → transfer down → ddev import-db → wp search-replace from the remote URL to the local one, across all tables, skipping guid → uploads, per strategy → scrub → the builder’s post-import steps → wp cache flush → the post-pull hook.

--db-only and --uploads-only are mutually exclusive. The scrub and the builder steps belong to the database import, so they run whenever the database is in scope and are skipped with it when it is not.

The snapshot taken first

Before anything is imported, cwp pull runs ddev snapshot --name pre-pull-<env>-<timestamp>, so a pull you regret is one cwp db restore away. Three things about it are deliberate:

• It comes after the confirmation, so a pull you refuse leaves nothing behind — not even a snapshot.
• A failed snapshot aborts the pull, exit 5. Every other late step degrades to a warning; this one may not, because a safety net you believe in and do not have is worse than none at all.
• A project with no WordPress installed yet is skipped with a reason rather than failed: the first pull into a fresh project has nothing to snapshot. When cwp cannot tell — a stopped DDEV project fails the probe exactly like an empty one — it takes the snapshot anyway.

Turn it off for one run with --no-snapshot, or for good with defaults.snapshot_before_pull: false in the machine config. Snapshots accumulate; cwp db list and cwp db rm are the answer, and nothing is pruned for you.

Example

cwp pull                       # dev, proxied uploads, scrub on, snapshot first
cwp pull prod --uploads sync   # a full copy of the uploads from prod
cwp pull --db-only --yes       # a fast database-only refresh, no prompt
cwp pull --no-snapshot --yes   # no restore point — you know what is local
cwp pull --dry-run --verbose   # print the plan and run nothing

Recovering the state a pull replaced:

cwp db list
cwp db restore pre-pull-dev-20260728-113000

What it does not do

It never writes upward. There is no flag on cwp pull that changes the remote beyond a temporary export file in the container’s /tmp, which it deletes again — including when the transfer fails.

The downloaded dump is deleted immediately after the import, so an unscrubbed copy of production does not linger on your disk.

It does not fetch themes or plugins. Those are code, they are gitignored, and cwp fetch is the command that brings them down.