Storage & Configuration

Storage model

WPChangeSync writes exports as structured, human-readable JSON so changes can be reviewed, committed, and moved between environments. Integration manifests define what each file contains and where it lives. Choose the location under Settings, then Storage:

• Child theme/wpchangesync/, recommended for Git, because the files are committed along with your child theme. This option only appears when a child theme is active, and WPChangeSync will never write into the Bricks parent theme.
• wp-content/wpchangesync/, a good default when you would rather not write into a theme directory. It survives theme changes.
• wp-content/uploads/wpchangesync/, best when uploads are already backed up separately or synced through a CDN.
• Custom path, any writable directory. This is how you point several sites at one shared location.

File naming is configurable too: the settings filename, and the templates filename pattern where {id} stands in for the template ID. An excluded-options list keeps values such as licence keys out of exports.

Current Status on the same screen tells you whether the folder exists and is writable, and offers a Create Directory button when it does not. On multisite the path shown resolves through the same network then site precedence the sync engine uses, so what you see is what a sync will actually write.

Configuration areas

General controls default sync behaviour, site role, sync mode, integration visibility, and your custom data sources. Storage controls where exported JSON and backup data live. Remotes & Groups store authenticated targets for push/pull. Tools holds housekeeping utilities, including a clean-slate reset.

Sync modes

Two settings on Settings, then General decide how much happens without you.

Site Role controls whether this site may receive data at all:

• Child (Receiver): can pull and receive data from remote sites. Use it for development and staging.
• Parent (Source Only): protected from receiving data, and can only push out. Use it for production.

Sync Mode then controls what triggers a sync:

• Manual, the default and the safest: nothing syncs unless you run a workflow or act in the Library.
• Automatic: changes are exported to JSON storage whenever templates are saved.
• Workflow: saving a template runs a workflow instead, so you can export and push to a remote in one move.

In Automatic mode, Auto-Export on Save decides what is included, with a master switch plus a checkbox per data type. It does not apply in Workflow mode, where the workflow itself defines the scope.

Leave this on Manual unless you specifically want automation, and verify a manual round-trip first. Imports only add and update data, they never delete meta that a payload omits, but automatic sync on production still deserves a staging rehearsal.

Recommended workflow

Export to storage, inspect the JSON diff, commit the intended changes, then import or push only after review. For broad content moves, combine a dry run with a deliberate conflict strategy before touching production.

If you are version-controlling the output, child-theme storage plus an export workflow is the cleanest setup: make the change, run the export, then commit the JSON with a meaningful message so review happens in a pull request instead of on the live site. Set sync mode to Manual and let the workflow be the only thing that writes.

Tools and clean-slate reset

The Settings, then Tools & Cleanup tab holds housekeeping utilities, including Delete All Plugin Data, a true clean-slate reset.

It clears every WPChangeSync option (settings, remotes, workflows, custom sources, licence state), the audit and activity tables, and per-user flags such as dismissed banners and the welcome modal. Afterwards the plugin behaves like a brand-new install.

Your exported JSON files are kept by default, since they may be your backups or under version control. A separate checkbox deletes those as well if you want a genuinely clean slate. The reset cannot be undone, so export anything you want to keep first. Remotes store encrypted credentials, so you will need to re-enter application passwords when you add those remotes again.

Deactivating versus deleting the plugin. Deactivating stops WPChangeSync running but changes nothing else: settings, remotes, workflows and exported files are all still there when you reactivate.

Deleting the plugin through WordPress runs a full cleanup of the database side: every plugin option, its transients, its own database tables, its scheduled events, and per-user flags such as dismissed banners and onboarding state. On multisite that cleanup runs for every site in the network, plus the network-level options.

What deleting the plugin deliberately does not touch is your files. Exported JSON and template version history are left on disk, on the grounds that they are often the only copy of something. So to leave a clean database but keep your exports, deleting the plugin is enough on its own. If you want the exported files gone too, run Delete All Plugin Data with the file checkbox ticked before you delete the plugin.

Reference checklist

Keep storage paths writable, keep secrets out of Git, and keep environment-specific remote settings separate from the exported JSON payloads. If a location cannot be created automatically, for example a read-only theme folder, the Storage screen explains the permission fix or suggests wp-content/wpchangesync/ instead. Once Current Status shows a green OK, the site is ready to sync.