FAQ

This is an attempt to explain what wordmove-ng is doing behind the scenes.

It started with an explicit request in welaika/wordmove#337 by @COLABORATI; in certain scenarios it is important to know the details.

Ask in issues if you'd like maintainers to add answers, or add questions with answers here. Just do not delete older ones without asking.

which transport mechanism is used?

SSH only. Directory sync is rsync -e ssh; remote commands, single file transfers and remote hooks use the system ssh and scp binaries. There is no Ruby-side SSH implementation, so anything that works for ssh on your command line (agent, ~/.ssh/config, ProxyJump, hardware keys) works here. FTP was removed in 6.0.

what exactly happens with the old database?

The old database of the target is always saved inside the local wp-content folder before the import: local-backup-TIMESTAMP.sql.gz during pull, REMOTE-backup-TIMESTAMP.sql.gz during push. The source database is only read, never modified.

how are URLs and paths rewritten?

After the import, wp search-replace runs on the target (locally after a pull, over SSH after a push) for vhost and then for wordpress_path, with --all-tables --skip-columns=guid. wp-cli unserializes PHP data properly, so serialized options and widgets survive. Post GUIDs are left alone as WordPress recommends. --no-adapt skips this step.

is there any kind of rollback?

The backups above allow manual restores: gunzip < wp-content/production-backup-TIMESTAMP.sql.gz | mysql … on the affected side. If the remote search-replace fails after an import, the log names the backup file to use.

where are files stored?

wordmove-ng only stores its own movefile.yml and the backups inside the local wp-content folder. Temporary dump.sql / dump.sql.gz files are created in wp-content on both sides during a database sync and removed afterwards.

is this a transactional process, e.g. what happens when a transfer is disrupted?

Before touching either database wordmove-ng checks that every needed program exists on both sides, so a misconfigured host fails before any side effect. An interruption in the middle can still leave a dump.sql or dump.sql.gz in a wp-content folder, and an interruption between import and search-replace leaves the target with the source's URLs (re-run wordmove-ng push -d, or the wp search-replace by hand). Enable global.maintenance_mode to hide that window from visitors.

what else are you doing on my wordpress server?

wordmove-ng works by mirroring folders: files deleted at the source are deleted at the destination too. Put what you need to keep in exclude. Nothing else is left behind.