Diagnose connection issues, import failures, storage problems, and UI/runtime mismatches.
Updated July 2026·WPChangeSync 2.1
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.
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.
