cwp inventory apply

cwp inventory apply [env] [flags]

This name is an alias. The work moved to cwp push --only inventory, 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.

tree → site

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

Flag	What it does	Default
--prune	also delete plugins and themes inventory.yml does not list	off
--exact	install the recorded version over a different one	off
--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

apply installs what inventory.yml lists and the site is missing. Then it activates and deactivates plugins to match the file.

cwp does not know where a plugin came from unless the file says so. wp plugin list has no field that tells a wordpress.org plugin from a premium one. On a real install Bricks and your own site plugin both report update: none. Where nobody has written a source:, apply tries the slug and then names exactly what it could not get:

! apply — 4 applied, 1 failed
! 1 item(s) could not be installed from wordpress.org — install them yourself:
  bricks 2.4 — bricks: Plugin not found.

The failed line is not an error. A premium plugin is a normal thing to have. The line tells you what to install by hand.

Additive by default. apply leaves a plugin alone when it is present but unlisted. --prune deletes it, and the confirmation names every plugin it would remove. apply reports a version difference and does not correct it. --exact installs the recorded version over what is there.

Where an item comes from, and where it belongs

Two optional fields on an entry change what apply does with it. Every file written before them lacks both, and an absent field keeps the old meaning:

plugins:
  - name: some-plugin
    version: 0.5.0
    status: active
    source: https://example.com/some-plugin-0.5.0.zip
  - name: query-monitor
    version: 3.20.0
    status: active
    environments: [local]

apply hands source: to wp plugin install instead of the name. Anything WP-CLI takes there works: a URL to a ZIP or a path. The source also decides the version, so --exact does not pin one beside it. A URL already names one build, and --version= would send WP-CLI to wordpress.org for a plugin that is not there. Nothing checks that a pinned URL and the version: next to it agree.

A path is relative to the project, and it travels. The install runs on the environment, where nothing of your repository exists. So cwp puts the file there first, installs the copy and removes it again. Both writes are in the plan:

↑ upload media/acme.zip to dev
✓ install theme acme 2.0 from media/acme.zip
✓ remove the staged copy of media/acme.zip

cwp refuses a path that names no file in the working copy before anything runs. Against the local site cwp stages nothing: the same filesystem is already there.

environments: names the environments the item belongs on. An absent field means everywhere. apply skips an entry scoped elsewhere and says which ones it skipped. --prune never deletes such an entry: the file records it for another environment, and pruning removes only what the file does not list.

Both fields are yours to write. Nothing on a site records either, so snapshot carries them forward rather than discovering them.

Against a remote this is an upward write with the full guard set. Installing or deactivating a plugin changes what a live site does.

WordPress itself goes one way only

Locally, apply also updates WordPress and installs the translations the file records. Core goes first. Otherwise a plugin lands against the older core and again after the update:

✓ update — update WordPress 7.0.2 → at least 7.0.3
✓ database — update the WordPress database
✓ install — install language de_DE

Against a remote it does neither. This is not a limitation to lift later. Code flows up and data flows down; a core update is neither. WordPress is the platform, and the host owns it. On a managed host the update is already automatic. Reaching up to change WordPress itself would be the most invasive write cwp offers.

The recorded version is a floor, never a target. wp core update --minor moves a site that is behind onto the current release of its own branch. A site ahead of the file is not drift, and nothing happens to it. No flag downgrades WordPress.

apply installs the recorded locale and switches to it, locally. core.locale is the language you write the project in. settings/ refuses to carry WPLANG because this file owns it. So this is the step that puts a site into the language its own record names:

✓ install — install language de_DE (active)

apply leaves a locale that is already in use alone. It installs a translation that languages lists and core.locale does not name, and does nothing more with it. Nobody asked for it to be the language of the site.

cwp never switches a site to en_US. A file with no core: block parses as en_US, so a recorded default and a silent record are the same bytes by the time apply reads them. An old file that says nothing is not an instruction to switch a German site to English.

Example

cwp inventory apply              # make this machine match inventory.yml
cwp inventory apply --dry-run    # what would change
cwp inventory apply prod --force # bring a protected environment into line

What it does not do

It fetches no premium plugins and stores no licence keys.

It never writes upward to inventory.yml. The file is the source, and snapshot is the only command that writes it.

It updates no plugin or theme. One that sits active at the recorded version stays exactly as it is. WordPress core is the single exception, and only on the local site.

It does not switch the language of a remote, and it does not update WordPress upward. Both are local-only. The platform belongs to the host.