cwp content status

cwp content status [env] [flags]

This name is an alias. The work moved to cwp status --drift, and that page documents it. This spelling still runs for one minor cycle.

Acts on the local site. Name an environment to act there instead.

Argument	What it is	Default
[env]	environment to compare (default: default_environment in cwp.yml)

Flag	What it does	Default
--all	list every post, including the ones in sync	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

Says what differs between the committed tree and a site, in both directions, writing nothing.

It is the same drift calculation cwp status --drift reports per artifact, here reported per page. Three states matter, and the command tells them apart:

• the tree has a page the site does not;
• the site has a page the tree does not;
• both have it and they differ. Then _cwp_sync records whether the tree moved or the site did.

That last distinction lets push refuse a page an editor changed on the target rather than overwriting it.

A project that carries menus gets one row per navigation, not one per entry. The whole menu is the artifact, so its state is one answer. A project that declares taxonomies: gets one row per term, under the type term and named <taxonomy>/<slug>. A term is what a consolidation renames, merges and removes. Its state is the one somebody wants.

The command compares all three the same way, against the _cwp_sync marker cwp leaves on the post or on the term. It adopts nothing to produce the comparison. A term the site has never given an identity therefore reads not tracked. The command does not give it one here.

The rows that ask for nothing are one line

A healthy site is mostly pages that are identical on both sides, and a screen full of them is where the one page that differs hides. So they collapse:

✓ 15 in sync
  type  slug     state
! page  kontakt  changed both sides
– menu  primary  changed in tree

A state says what is true and never what to do about it. The closing block says what to do. A cell that also instructs is two sentences in one column.

--all prints every row instead, for the inventory rather than the difference.

--json keeps its shape, except that these rows are no longer in steps. data.items carries every one of them with uid, group, postId and state, more than the step ever had.

It closes with what to do about it

A state is not an instruction. The reader looks at the output precisely because they do not yet know which command follows from it. So the run ends with one block per state it found, most expensive decision first:

what to do next:
  1 post(s) changed on dev *and* in the tree — cwp will not pick a side
  → cwp content pull dev --post kontakt — take dev's version; git still has the file's
  → cwp content push dev --post kontakt --overwrite-conflicts — take the tree's version; the push names what it can roll back to
  2 post(s) changed on dev — somebody worked there since cwp last looked
  → cwp content pull dev --post about-us --post impressum

Three things about it are deliberate:

• The both-sides state leads. It is the only one where either direction discards somebody’s work. Reaching for pull because it sounds like the safe direction is the expensive mistake here.
• The commands name the posts rather than offering --all. --all would carry posts in the opposite state along with them. Past three, the line ends in a shell comment counting the rest. It stays runnable and does not pretend to cover what it does not name.
• A menu and a term go to --all, because --post applies to neither. The reasons differ and the comment on each line says which: a menu travels only in a whole-group run, while a term travels with its group whatever the run named.

--json keeps its shape. The block is human output, and a machine caller reads the same facts as states in data.items.

Example

cwp content status          # against the local site
cwp content status dev
cwp content status --json

What it does not do

It writes nothing to the site and nothing to the tree, not even a uid adoption. It is safe against production and safe on a protected environment. There is nothing for a guard to stop.