Diagnose connection issues, import failures, storage problems, and UI/runtime mismatches.
Updated October 2026·WPChangeSync 2.2
Start narrow
Almost every problem falls into one of six buckets, and naming the bucket first saves a lot of time: connection, authentication, storage, compatibility, import data, or PHP runtime.
The most common causes and their fixes:
Directory not found. Use the Create Directory button on Settings, then Storage.
Permission denied. The web server needs write access to the storage folder. Check ownership and permissions, or switch to wp-content/wpchangesync/.
Import stalls or times out. Enable batch mode for the step, and raise memory_limit for very large imports.
Duplicate media after an import. Media is matched by its attached file path and slug, never by attachment ID, because IDs differ per site. Keeping filenames and slugs stable across sites is what lets an existing attachment be reused.
Connection refused or 401. Both sites need HTTPS, an admin-capable Application Password (not the login password), a reachable /wp-json/, and WPChangeSync active on both ends.
The plugin also ships in-plugin guides for connection issues, import failures, storage issues, debug mode, duplicate media, and global style warnings, each with the exact screen to open.
Checklist
Confirm WPChangeSync version compatibility on both sites.
Confirm HTTPS and Application Password auth for remotes.
Check storage path writability.
Run a dry run before production imports.
Inspect Activity and workflow run details.
Check PHP logs for fatal errors or missing handlers.
Start with Test connection. In Settings → Remotes, Test connection checks plugin versions, whether the remote can download files from this site, SVG permission, the upload limit, Bricks and languages, and says what to fix.
The push preview isn't shown, or Undo last push isn't available. Update the remote to 2.2 too; both features need 2.2 on both sites.
Pushed images or SVGs are missing on the destination. Check the push notice for "Media not imported". For SVGs, the destination must allow SVG uploads for the user your remote connection signs in as.
Images are missing although this site is public. Pushes detect a remote that can't download from this site and send the files inside the push. If the remote runs an older version, tick Always send files with pushes to this remote in Settings → Remotes.
Bricks custom fonts don't arrive. Update to 2.2 and include Global Styles in the export or push; the font files are copied into storage and restored on import.
A translation arrived without its link (WPML or Polylang). Import or push its original too; the link is completed automatically as soon as the original arrives. The multilingual plugin must be active on both sites with the same languages.
Bricks templates show as changed right after exporting. Re-export them once on 2.2. Older template files contained the site's internal version history.
"A push to this remote is already running". Wait for it to finish (the Library shows its progress) or cancel it first; one push per remote runs at a time.
Remote API errors
Remote import errors are deliberately sanitised before they are returned to the caller, so the pushing site sees that something failed without leaking internals of the receiving site. That is intentional, and it means you look in a different place.
When a remote push fails, open the target site's Activity screen for the real error, then its PHP error log if the failure happened below the plugin. Before retrying, confirm both sites run compatible plugin versions, and remember that credentials are dropped rather than sent if a remote redirects HTTPS to plain HTTP, which looks like an authentication failure but is really a redirect problem.
wp wpchangesync status
wp wpchangesync integrations list
wp wpchangesync config get storage_path
Reference checklist
The fast checks, roughly in the order they pay off: plugin version compatibility on both sites, HTTPS on both sites, a valid admin-capable Application Password, storage folder permissions and a green status, the Activity log on whichever site actually failed, and finally the PHP error log. Enable debug logging from the Activity screen only while you need it, and turn it off again on production.
