Solving WordPress Site Sync Challenges: Key Insights & Solutions

Skip to content

General, automated WordPress-to-WordPress sync is unsolvable

Posted by

Adam Zieliński

on

June 10, 2026

Twenty-three years into WordPress, the general problem of site synchronization is still unsolved. We have great tools for the slices, but nothing for the whole. You can’t reliably automate any of these tasks beyond basic sites:

Export posts, media, Woo products, and all their associated plugin data, and import it all on another live site.

Publish posts on a staging site and sync them to the production site upon acceptance.

Clone a live site, install and configure a plugin, and deploy it all back to production.

Build a site locally, deploy it to production, and re-deploy as the local site evolves.

Migrate the entire site to another host.

This post exhaustively covers what makes these problems so difficult, and what we can do instead. It is a 2600 words deep dive. It reflects many discussions I’ve had with Dennis Snell over the years, as well as what I’ve learned from WordPress.com, the WordPress importer plugin, the Site Transfer protocol, Playground, the more recent Reprint, ForkPress, and more.

Get some coffee, clear your calendar for an hour, and join me on this ride!

What’s difficult about syncing?

The holy grail of WordPress↔WordPress synchronization is this:

I connect Site A to Site B.

I can now click Push or Pull buttons to move the data in either direction.

Optionally, I can choose which posts, products, or plugins I want to sync.

It’s effectively the same as a hostless, Peer↔Peer WordPress.

I claim that such an automated, generalized sync is not possible.

There are more limited forms of syncing WordPress could have. We’ll explore them later in this post, but now let’s discuss the constraints we’re facing.

Migrating a site to a different environment

A WordPress Site = Database + Files + Environment. We can only sync Site A with Site B if their environments match closely enough. That is, all of these and more:

Operating system, locally available software, cron, env variables, memory and disk space, and web services in the local network.

Additional HTTP response headers, HTTPS support, access policy for /wp-content/ files, special routing rules, pretty permalinks support, web-accessible directories, edge cache rules, all the associated domains, loopback request support, and whether there is a public IP Jetpack could connect to.

PHP version, extensions, php.ini settings, disabled functions, auto_prepend_script, host-provided constants, and number of PHP workers.

MariaDB version, my.cnf options, user permissions, character set, and table engine. MyISAM and InnoDB are very different!

File layout, side-loaded plugins, host-specific plugins, symlinks pointing outside of the site root, read-only files, file owners and permissions, and tmp directory path.

When the environments don’t match, we’ll observe:

Database connection errors: Site A uses the wp_ table prefix, Site B enforces a site_14718_ prefix, and a plugin hardcodes wp_.

An order gets placed when it shouldn’t: SQL ROLLBACK fails in production because all the tables are MyISAM.

Text data corruption: Ziółkowski becomes Ziółkowski because local tables use utf8mb4 declared via DB_CHARSET, and the production host ignores DB_CHARSET and enforces latin1.

Exposed private data: A source host protects wp-content/uploads/precious-ebooks/ with .htaccess rules, but after syncing to target host, which runs nginx, those files are exposed to the world.

Non-loading site: A remote site only has 2 PHP workers, so a wp-cron task using a loopback request locks all the visitors out.

Missing automated emails: The site sends emails using cron, loopback requests, Redis, and sendmail, but the new host doesn’t support one of these things. We only realize something’s wrong two weeks later.

Missing images: A site exported from WP Cloud has no thumbnails, as WP Cloud generates them on the fly when you request wp-content/uploads/my-photo-512x512.jpg.

Invoices stop generating at checkout: The new host disables proc_open/exec that the PDF/image library shells out to.

CSS vanishes after deploy: Page builders write generated CSS into wp-content/uploads; the new host has a read-only filesystem, the write fails, and the whole site renders unstyled.

…and many, many more issues. Some are benign, and some are catastrophic. Some are solvable, and some aren’t. The absolute worst scenario is when the site looks good after syncing, and then two weeks later, we detect a serious and irreversible data leak, loss, or corruption.

We can’t automatically detect most of these mismatches. How would we know Site B only runs 2 PHP workers? Or that our 24th plugin relies on Redis in specific code paths? Or that Site A had a special thumbnail-generating route? The PHP extensions rarely match exactly, but how do we know if that matters? The best we can do is compare the PHP...