cwp bricks post-types enable
shipped 1.0.0cwp bricks post-types enable <slug> [env] [flags]
Acts on the local site. Name an environment to act there instead.
| Argument | What it is | Default |
|---|---|---|
<slug> | post type slug | |
[env] | environment to write to (default: default_environment in cwp.yml) |
| Flag | What it does | Default |
|---|---|---|
--force | override the protected-environment refusal | off |
--no-backup | skip the remote backup taken before the write | on |
--yes | skip the confirmation prompt | off |
--with-agent | with —dry-run on a host with no shell: install and remove the PHP agent so the plan is real | off |
Plus the shared flags --json, -v, --verbose, -q, --quiet and --dry-run.
What it does
Adds one post type to the list the Bricks builder will open for.
Against a remote this is an upward write and carries the guard set. A
protected environment refuses without --force. cwp asks you to confirm the
change and takes a remote backup first.
The change is database state, so it does not travel. Enabling a post type locally and deploying code will not enable it on production. Run the command against each environment that needs it.
Example
cwp bricks post-types enable buch
cwp bricks post-types enable buch prod --force
What it does not do
It does not register the post type. If the slug does not exist on the target,
enabling it in this list achieves nothing. The site plugin registers it, and
cwp deploy moves the site plugin.