cwp deploy
shipped 1.0.0cwp deploy [env] [flags]
Acts on dev unless another environment is named.
| Argument | What it is | Default |
|---|---|---|
[env] | environment to write to | dev |
| Flag | What it does | Default |
|---|---|---|
--force | override the protected-environment refusal | off |
--no-backup | skip the remote backup taken before the transfer | on |
--delete | mirror: also remove remote files that are absent locally | off |
--yes | skip the confirmation prompt | off |
Plus the shared flags --json, --verbose and --dry-run.
What it does
Everything cwp push does, and then the remote post-steps:
wp cache flush, the builder’s own regeneration — for Bricks, the CSS — and the
post-deploy hook.
push and deploy are generated from one factory in the command manifest, so
their arguments, their flags and their guard ladder are the same objects rather
than two lists that have to be kept in step. Read cwp push for the
guards, the verification and the --delete semantics; all of it applies here
unchanged.
Use deploy unless you have a reason not to. push moves the files and
leaves the site holding a stale cache and, on Bricks, stale generated CSS — which
looks like a deploy that did not work.
Example
cwp deploy dev # the ordinary case
cwp deploy prod --force # prod is protected; --force is required
cwp deploy dev --delete # make the remote match local exactly
What it does not do
It does not push the database, and it does not run the post-steps during a dry run — a dry run runs no hooks at all.
It does not deploy anything outside tracked. If a change needs a plugin that is
not there, that is cwp plugins apply.