Site actions#

Site actions are things the remote site does to itself on request: the steps of a deploy that otherwise need a person logged in there. They are on the Site tab and in wp bb-migrate site and wp bb-migrate meta.

wp bb-migrate site <action> "<connection>" [<args>…] [--yes]
wp bb-migrate meta push "<connection>" <post> <keys>… [--type=<post_type>] [--yes]

What they need on the remote#

Action	`allow_push`	`allow_code_files`	Other plugin on the remote
`plugins` (list)	yes	no	none
`activate`, `deactivate`	yes	yes	none
`cache`, `cache-set`, `cache-copy`	yes	no	BB Cache
`purge`	yes	no	none (BB Cache when present)
`snippets`	yes	no	Custom CSS & JS
`meta push`	yes	no	none (ACF for field references)

Every site action is served by a write route, so even the two that only read (plugins, cache) need "Accept push". Activation and deactivation also need "Allow code files" because they run plugin code.

Site actions run with the full site loaded: the compatibility mu-plugin leaves site-* routes alone. Plugin activation and deactivation and a change to the BB Cache settings run as the site's first administrator (the administrator with the lowest ID), because activation hooks and purge callbacks may check capabilities.

None of them is retried by the client. If a reply is lost, check the state (site plugins, site cache) before running the action again.

Plugins#

List#

wp bb-migrate site plugins "<connection>"

Prints a table of every installed plugin: slug, name, version, active or inactive. The slug is the plugin's folder name (or the file name without .php for a single-file plugin).

Activate and deactivate#

wp bb-migrate site deactivate "<connection>" some-cache-plugin another-plugin
wp bb-migrate site activate "<connection>" bb-cache

Plugins are named by folder slug; a plugin file such as bb-cache/bb-cache.php is accepted too. Activation runs the plugin's activation hook. One line is printed per plugin:

Outcome	Meaning
`activated`, `deactivated`	Done
`already active`, `already inactive`	Nothing to do
`not installed`	No plugin with that slug on the remote
`error: <message>`	Activation failed; a fatal error or stray output during activation is reported here
`error: still active`	Deactivation did not take effect
`refused: the plugin serving this request`	BB Migrate does not activate or deactivate itself

Both ask for confirmation on the command line unless --yes.

A typical order for a plugin deploy: push the files, wait for the server's opcache to notice them (Hosting notes), then activate.

wp bb-migrate files push "<connection>" --scope=plugin:bb-cache
wp bb-migrate site activate "<connection>" bb-cache --yes

BB Cache settings#

These actions address the BB Cache plugin on the remote. Without it, cache reports BB Cache is not active on the remote. and cache-set fails.

Show#

wp bb-migrate site cache "<connection>"

Prints the remote's BB Cache settings, one key value line each. A stored Cloudflare API token is shown as (set); the token itself is never sent back.

Set#

wp bb-migrate site cache-set "<connection>" lazy_videos=1 varnish_host=127.0.0.1

Each key=value is merged into the remote's settings:

Only keys that exist in BB Cache's own defaults are accepted. Unknown keys are ignored. No other option can be written through this action.
The value is cast to the type of the default: integer, list or trimmed string.
A few keys are validated: varnish_host must be a host name or IP with an optional port, sitemap_url an http(s) URL, cf_zone a 32-character hex ID, cf_token a token of at least 20 characters, cf_purge_mode either urls or all.
If anything changed, the remote saves the settings through BB Cache's own save routine and purges.

The reply lists what changed, or No change (already set).

Copy#

wp bb-migrate site cache-copy "<connection>"
wp bb-migrate site cache-copy "<connection>" varnish_host=127.0.0.1

Sends this site's BB Cache settings to the remote, then applies them as cache-set does. BB Cache must be active on this site too. key=value pairs after the connection override or add to the copied values.

Settings that belong to one server are site-specific and never copied:

Group	Keys
Server	`varnish_host`, `critical_dir`, `sitemap_url`, `htaccess_rules`
Cloudflare	`cf_purge`, `cf_zone`, `cf_token`, `cf_purge_mode`, `cf_edge_ttl`

To set one of them on the remote, name it explicitly, as with varnish_host above.

Purge#

wp bb-migrate site purge "<connection>"

Fires bb_cache_purge_all on the remote and flushes its object cache. The reply says whether BB Cache answered (BB Cache purged on the remote.) or not (Remote has no BB Cache; its object cache was flushed.).

Snippets#

wp bb-migrate site snippets "<connection>"
wp bb-migrate site snippets "<connection>" 1412 1413

Rewrites the served files of the remote's published Custom CSS & JS snippets from the database, rebuilds the snippet plugin's search tree and its URL-rules index, and purges the cache. With IDs (the remote's post IDs), only those snippets' files are rewritten; the tree and the index are always rebuilt in full. The reply lists the files written.

Use it after snippets reached the remote by a database push. A page package does the same for the snippets it carries. A snippet whose options do not describe a css, js or html snippet is left alone and logged on the remote.

Meta#

wp bb-migrate meta push "<connection>" home hero_video_poster
wp bb-migrate meta push "<connection>" 1523 components_4_video_poster components_4_title --type=page --yes

Copies one or more meta values from a local post to the same post on the remote, found by the local post's slug and type (--type overrides the type). It changes one field without re-sending the page.

Argument	Meaning
`<post>`	The local post: ID, slug or URL
`<keys>…`	Meta keys to copy. Each must exist on the local post
`--type=<post_type>`	Post type for the slug match on the remote. Default: the local post's type
`--yes`	Skip the confirmation

What travels with each key:

the value,
the ACF reference (the hidden _<key> row holding the field key), so ACF reads the value on the remote,
for ACF image, file and gallery fields, the upload path of each attachment instead of its ID. The remote resolves each path to its own attachment ID.

The attachment must already exist on the remote. Push the file first as a package item:

wp bb-migrate pages push "<connection>" 2026/10/poster.jpg
wp bb-migrate meta push "<connection>" home hero_video_poster

The remote reports one line per key:

Report line	Meaning
`<key>: written`	Done
`<key>: no attachment for <path> here; push the file first …`	The file is not registered on the remote
`<key>: skipped (hidden keys are written through ref)`	Keys starting with `_` cannot be written directly
`options: refused (not a css/js/html snippet)`	A snippet's `options` failed the snippet check

It fails with No <type> with slug "<slug>" on this site. when the remote has no such post. After writing, the remote clears the post's cache and purges.

In the admin screen#

The Site tab has a button per action: list plugins, activate and deactivate (slugs in a text field), show BB Cache settings, copy this site's settings, apply key=value pairs, purge, and rewrite snippet files (all published snippets). The result is shown as text. meta push is command-line only.