cwp bricks push

cwp bricks push [env] [flags]

Acts on the local site unless an environment is named.

Argument	What it is	Default
[env]	environment to push to (omit for the local site)

Flag	What it does	Default
--replace	overwrite items that already exist, instead of skipping them	off
--sensitive	include the api-keys and custom-code settings tabs	off
--force	override the protected-environment refusal	off
--no-backup	skip the remote backup taken before the write	on
--no-snapshot	skip the local design-system export taken before —replace	on
--yes	skip the confirmation prompt	off

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

What it does

Zips the committed tree back up, inspects it, shows you what collides, then imports it.

Conflicts default to skip. --replace overwrites, and the confirmation names the items it would overwrite rather than leaving it to a flag you typed moments earlier.

--dry-run inspects for real, so the conflict counts it shows are the actual ones.

Against a remote this is an upward write

It carries the full guard set: a protected environment refuses without --force, nothing transfers without confirmation, and a remote backup is taken first. “It is only design data” is not a reason to relax any of that — --replace across a site’s global classes is worse than most file pushes.

The design-system snapshot

Bricks revisions the element tree of a post, so a bad page comes back. It does not revision global classes, variables, colours or theme styles: deleting one is immediate and final, and the only net was remembering to export first.

So cwp exports for you. Before a destructive write against the local site, it writes the current design system into .cwp/bricks-snapshots/<timestamp>/:

✓ design-system snapshot — restore with: cwp bricks push --replace

• Two commands take it: this one with --replace, and cwp ability when the ability declares itself destructive and its category is one an export can restore. The plain ability door is how a class actually gets deleted, and a net it walks around is not a net.
• A remote takes none. The host’s backup in the guard set already covers it — the same split as cwp pull taking a local snapshot while cwp push takes a remote backup.
• A failed snapshot aborts the write. Nothing is deleted if the restore point could not be made.
• It is a directory, not a commit. cwp touches no git repository, and the directory ignores itself so it never shows up in git status. Snapshots accumulate and are never pruned.

Recovery is this command with --replace and builder.options.export_dir pointed at the snapshot. Switch it off with --no-snapshot per run, or cwp config set defaults.snapshot_before_bricks_write false for good.

Example

cwp bricks push                          # into the local site
cwp bricks push --dry-run                # what would happen, checked for real
cwp bricks push prod --replace --force   # overwrite on a protected environment

What it does not do

It does not create post types. A template whose condition names a post type the target does not register imports cleanly and then matches nothing, so cwp warns per unknown slug and tells you to cwp deploy the site plugin first. It warns rather than aborting, because an intentionally inactive template is legitimate.