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 group
Purpose
status
Show license, storage, sync mode, and integration status.
integrations
List active integrations and inspect their capabilities.
settings
Export/import supported settings.
templates
Export/import Bricks templates where Bricks is available.
components
Export/import Bricks components where Bricks is available.
config
Read or update site, group, and network configuration values.
workflow
Run, dry-run, inspect, and automate workflows.
demo
Seed or remove sandbox/demo data for guided testing.
Dynamic integration commands
Expose 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.