Cloning WordPress Sites with Pagely Sync
Last Updated -
By using the Pagely Sync tool, you can easily create one-time copies of your site without the manual process of copying, pasting, exporting, and importing.
This article covers utilizing the Pagely Sync command for syncing your files and database between sites. It is a useful tool for one-time copies of a single site application. If you need more granular, repetitive, or multisite cloning processes, we recommend using the Pagely Cloning Tool.
To use Pagely Sync, you'll need to log into your Pagely site using SSH. Once logged in, you can run the following to see all available parameters for the Pagely Sync command:
pagely sync --help
Here's what you'll see when accessing the --help parameter:
Usage: sync [--ignore-table[="..."]] [--ignore-path[="..."]] [--target-host="..."] [--ssh-identity="..."] [--dry-run] [--skip-file] [--skip-db] [--rename] source target Arguments: source The source directory target The target directory Options: --ignore-table[=IGNORE-TABLE] Ignore this table while syncing db (multiple values allowed) --ignore-path[=IGNORE-PATH] Ignore this path, rsync rules (multiple values allowed) --target-host=TARGET-HOST Remote host to use in rsync target --ssh-identity=SSH-IDENTITY ssh identity file to use with rsync --dry-run Print what you would do --skip-file Don't sync files --skip-db Don't sync db --db-recent-only Only sync the last 100 posts from wp_posts (and children) and there matching rows in post_meta --limit-to-multisite[=LIMIT-TO-MULTISITE] blog_id of sites you want to limit the sync to, only applies when db-recent-only is set, repeatable (multiple values allowed) --reset-target-db Delete all tables in the target db before syncing, useful when the source has a different table prefix, or the target has extra tables --rename Update wp_options/wp_blogs and search/replace at target, with targets orginal name (on multisite only renames the primary domain) -h, --help Display this help message -q, --quiet Do not output any message -V, --version Display this application version --ansi Force ANSI output --no-ansi Disable ANSI output -n, --no-interaction Do not ask any interactive question -v|vv|vvv, --verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug
Creating a Staging Site from a Production Site
Pagely Sync is perfect for things like cloning sites between staging and production environments. If you don't already have a staging site to test changes before making them live, creating a staging site is a great way to get stared with Pagely Sync!
- Begin by logging into the server with SSH.
- Before cloning, you'll want to double-check the table prefix that your existing production site is using. You can check it from the SSH terminal by running the following:
cat ~/sites/production-domain-name/wp-config.php | grep '$table_prefix'If it's anything other than wp_, you'll want to edit your staging site's wp-config.php file and change it to the correct prefix that matches your current production site.
- Now it's time to do a quick test to make sure that everything runs properly before running the clone process.
To do a dry run of the Pagely Sync tool without making any changes yet, run the following command:
pagely sync --dry-run --rename ~/sites/production-domain-name ~/sites/staging-domain-name
- Did everything run successfully in the last step? Great! Now let's remove the --dry-run parameter to perform the sync from production to staging:
pagely sync --rename ~/sites/production-domain-name ~/sites/staging-domain-name
Once the Pagely Sync tool completes, your production site has been successfully cloned over to your staging environment!
Cloning a Staging Site Into Production
The process of cloning a staging site into your production environment is the same as cloning from production to staging, but in reverse. With that said, your command would look like this:
pagely sync --rename ~/sites/staging-domain-name ~/sites/production-domain-name
Of course, it's always a good idea to add the --dry-run parameter first. We all make mistakes, and using it makes sure there isn't an issue before the sync is fully executed.