BASIC

Sync

Sync moves the database and files between two sites that both run DevKit 3.0 or later. Typical use: pull production down to staging, or push a finished staging site live. One site issues a key, the other pastes it, and from then on the second site can pull from or push to the first.

1. Get the key from the other site

On the site you want to reach, open Sync → This Site's Key. DevKit shows a Connection key starting with dk1.. Press Copy key.

The key names the site and carries a secret, so treat it like a password. Anyone who has it can copy that site's database and files.

Regenerate makes a new one. Every site that pasted the old key loses access at once, and it is the only way to revoke a key you have shared.

Read-only key

Allow push to this site is off by default. While it is off, the site is read-only: sites with the key can pull from it, but cannot push to it or change anything there. Turn it on only for a site you want to push into. The switch saves itself.

If you try to push to a read-only site, DevKit tells you to turn the switch on at the other site first.

2. Paste it on this site

On the site you are working from, open Sync → Connect, paste the key into Connection key and press Save. DevKit shows the site's name and address from the key before you save.

Test connection checks that the other site answers and reports its WordPress, PHP and DevKit versions. It also tells you when the other site is read-only.

A site holds one connection at a time. Forget deletes the stored key from this site only. Nothing changes on the other site.

If either site is reached over plain http://, DevKit warns you: the key and all the data would cross the network unencrypted. Use https:// on both ends.

3. Pull or push

Open the Pull or Push tab:

  • Pull copies the database and files from the connected site to this one.
  • Push copies them from this site to the connected one.

Choose what to include:

  • Database. Press the link next to it to open Choose Database. On the Tables tab, tables you leave unticked are not touched. On the Content tab you can sync individual post types instead: content is added and updated, never deleted, and the attachments it uses come with it. For media you choose whether to copy the files and Media Library entries across, or leave them linked to the other site.
  • Files. Plugins, themes and uploads, each with its own checkbox. Files are mirrored: the receiving site ends up identical to the source, and files that exist only on the receiving site are deleted.
  • Keep my admin account (pull only). After the database is replaced your current user is re-created, so you stay logged in.

Before anything is replaced, DevKit takes a safety backup of the site being overwritten. URLs in the copied database are rewritten to the receiving site's address.

Press Start Pull or Start Push, then confirm with Pull and overwrite or Push and overwrite. A push asks you to type the other site's host as well. The sync runs on the server, so you can close the tab and come back to it later on the same screen.

Order of steps

A sync runs in this order, for a pull and a push alike:

  1. Safety backup of the site being overwritten.
  2. Uploads.
  3. Plugins.
  4. Themes.
  5. Database.
  6. Content, if you chose post types instead of the whole database.

Files come before the database. While plugins and themes arrive, the receiving site still runs on its own database and its own list of active plugins, so a plugin that is new to it stays inactive. Once every file is in place, the database arrives and activates the other site's plugins.

Each plugin and theme folder is built next to the live one, in a hidden folder called .devkit-incoming-<slug>, and swapped in whole when it is complete. The site never runs a half-copied plugin, not even for a moment. Uploads are copied file by file.

If something goes wrong

  • Cancel Sync stops the run. Anything already copied stays in place, and the safety backup is not touched.
  • If you cancel while the database is being imported, the database may be only half restored. Restore the safety backup from Backup.
  • If a pull fails after this site's database was replaced, even partly, DevKit restores the replaced tables from the safety backup by itself and removes the tables the pull added. The site is put back as it was before the pull. If that restore fails too, the message names the safety backup in Backup, so you can restore it from there.
  • "A sync or restore is already running there" means the other site is busy. Wait for it to finish, then try again.

Sites whose salts are not in wp-config.php

Sync and restore keep you logged in on sites whose salts are not set in wp-config.php, which includes every WordPress Studio site. No setup is needed.

Older DevKit on the other site

When the other site runs a DevKit older than this one, DevKit warns you before a push, on Test connection, on the Push tab and in the run's messages:

The other site runs DevKit 3.0.4. Update DevKit there before pushing: an older DevKit can leave that site half-restored when its salts are not set in wp-config.php.

The version in the message is the other site's. It is a warning, not a block: the push may well go through, but update DevKit there first.