Docs/WP-CLI

WP-CLI

Automate WPChangeSync from the command line for CI, release checks, and repeatable operations.
Updated June 2026·WPChangeSync 2.0

Command namespace

WPChangeSync registers commands under wp wpchangesync. Commands are intended for deployment scripts, CI checks, scheduled operations, support diagnostics, and repeatable agency workflows.

Most operations require an active WPChangeSync licence and the same WordPress capabilities that would be required in wp-admin.

Command groups

Command groupPurpose
statusShow license, storage, sync mode, and integration status.
integrationsList active integrations and inspect their capabilities.
settingsExport/import supported settings.
templatesExport/import Bricks templates where Bricks is available.
componentsExport/import Bricks components where Bricks is available.
configRead or update site, group, and network configuration values.
workflowRun, dry-run, inspect, and automate workflows.
demoSeed or remove sandbox/demo data for guided testing.
Dynamic integration commandsExpose list/export/import/status operations for enabled integrations when supported.
Common commands
wp wpchangesync status
wp wpchangesync integrations list --format=table
wp wpchangesync workflow run release-to-production --dry-run
wp wpchangesync workflow run release-to-production
wp wpchangesync settings export --output-file=settings.json
wp wpchangesync demo seed
wp wpchangesync demo reset

CI and deployment usage

Use WP-CLI as a release gate: verify the plugin is active, confirm the expected integrations are enabled, export current state, run workflow dry-runs, then execute only after review or approval.

For CI systems that cannot run WP-CLI directly on the WordPress host, use a secured workflow webhook instead and keep the webhook token outside the repository.

Release-script outline
wp wpchangesync status
wp wpchangesync integrations list --format=json
wp wpchangesync workflow run staging-to-production --dry-run
# Review output or require approval here
wp wpchangesync workflow run staging-to-production

Output formats

Commands that list or inspect data should prefer machine-readable output where implemented, such as --format=json, --format=table, or --format=csv. Not every command supports every format, so scripts should fail clearly when an expected format is unavailable.

Safety notes

  • Run destructive or broad imports with --dry-run first where the command supports it.
  • Keep CLI credentials and webhook tokens out of Git.
  • Run scripts as a user with the minimum practical WordPress permissions.
  • Log command output in CI so failed runs can be diagnosed later.
  • Pair CLI workflows with backups, conflict policies, and approval gates for production.