Content Sync
Pull content, users and options from one environment into another — refreshing staging from production, for example.
Content Sync (the yax-content-sync mu-plugin) copies content between WordPress environments: posts, media, terms, users and allowlisted options. The usual use is refreshing staging from production so QA happens against real content.
This is separate from the external data sync that pulls provider and rating data from Doctor.com and Press Ganey. That one brings outside data into the site; this one moves content between environments of this site.
It's a pull, and it overwrites. You run it on the environment you want to pull into, and it overwrites matching content there. Pull production into staging, never the other way around.
How it works
The destination site pulls from a source over the REST API and matches content by a stable UUID, so re-running a sync updates existing items instead of duplicating them. Dependencies are resolved automatically: terms and media an imported post relies on come across with it. It runs in batches, so large content types sync over several requests.
Set up a connection
Connections live under Content Sync → Connections (requires manage_options). Add one for each source environment:
| Field | What it is |
|---|---|
| Label | A friendly name, e.g. "Production" |
| Site URL | The source site's root URL, no trailing slash |
| Username | A user on the source with manage_options |
| Application Password | A WordPress application password for that user |
Use Test on a saved connection to confirm it can reach the source before syncing.
Run a sync
Go to Content Sync → Sync and:
- Source Connection — pick the environment to pull from.
- What to sync — a single content type (posts, providers, locations, etc.) or Users.
- Batch size — posts per request (default 5). Lower is gentler on memory; higher is fewer requests.
- Options:
- Trash orphans — posts on the target that aren't on the source are moved to Trash. Use it for a true mirror; leave it off to only add and update.
- Protect edits — shields content edited locally on the target from being overwritten (e.g. staging-only changes).
Then choose how to run it:
| Action | What it does |
|---|---|
| Run | Standard pull. Adds and updates matched content; respects Protect edits. |
| Force Sync | Same, but overwrites locally-edited content too (bypasses Protect edits). |
| Purge & Pull | Replaces the target's content for that type wholesale. The most destructive option. |
Progress shows in the Sync Progress panel as batches complete.
Purge & Pull and Force Sync bypass the edit protection. On a site with staging-only content you care about, prefer Run with Protect edits on, and reach for the destructive modes only when you genuinely want the target to match the source.
Good practice
- Direction is one-way in practice: production → staging. Pulling onto production would overwrite live content.
- Back up first when using Purge & Pull on anything you can't easily recreate. See Backups & Restore.
- Users sync is opt-in: choose Users explicitly, and filter by role where you only need some.
- Re-running is safe for additive syncs: UUID matching updates in place rather than duplicating.