WPChangeSync grew out of BricksSync, so Bricks remains deeply supported. In version 2.0, Bricks Builder is optional: when Bricks is absent, Bricks-specific screens and integrations are skipped while broader WordPress workflows remain available.
Use a maintained WordPress install. WPChangeSync 2.0 is tested up to WordPress 7.0; running the latest stable version is recommended.
The plugin requires PHP 8.0+. Use current supported PHP releases for security and performance.
Install Bricks when you want Bricks templates, components, styles, variables, classes, fonts, capabilities, and builder-panel workflows.
Templates, components, settings, global classes, theme styles, variables, colors, typography, breakpoints, custom fonts, custom CSS/code, icon fonts, sidebars, and more.
Bricks docs →Pages, posts, media, menus, widgets, categories, and tags.
Coverage matrix →Move field definitions and content structures that templates depend on.
ACF guide →Use Gutenberg workflows on non-Bricks sites and Bricks workflows where Bricks is installed.
Non-Bricks guide →Sync supported plugin-owned settings where manifests and handlers allow it.
Integrations →Use scriptable operations when the host supports WP-CLI and remote HTTP access.
WP-CLI docs →For site-to-site sync, use HTTPS, a reachable REST API, dedicated admin-capable credentials such as application passwords, compatible WPChangeSync versions, and server limits that can handle the payload size. Large sites should use batch controls and smaller scopes.
Remote URLs should use the current wpchangesync/v1 namespace, with the legacy bricks-sync/v1 namespace kept for compatibility where needed.
Store workflow webhook tokens in CI secrets or server configuration, not in Git or public issue trackers.
For large media libraries, multisite rollouts, or remote groups, use smaller chunks, dry-runs, monitoring, and retry-aware workflows.
If a plugin stores data in custom tables or unusual serialized option structures, verify coverage before promising a client workflow. Start with export-only checks, selected scope, staging imports, and dry-runs before production pushes.
Use the matrix and docs to confirm whether your plugin data is handled, ignored, or needs a custom integration.
Test on staging and choose conflict handling deliberately before touching production.
BricksSync customers keep the same licence and existing workflows should keep working after the name change.
