KLYRN
Install Free

    All documentation
    1. Home
    2. Docs
    3. WordPress staging

    WordPress staging

    Staging is a real second site: its own vhost, its own PHP pool, its own database, its own certificate. Not a directory, not a symlink, and not something that shares a database with live.

    Creating the copy

    klyrn site staging create example.com
klyrn site staging create example.com --domain test.example.com
klyrn site staging show example.com

    The default name is staging.<domain>. The copy lives in the same hosting account as the live site: same Unix user, same home, same disk allowance. Putting it anywhere else would make staging a way to move data between tenants.

    The copy is made in named steps you can watch: wpcli, files, db, data, config, urls, noindex.

    KLYRN refuses to create one when:

    • The site is not WordPress. Use klyrn wp clone instead.
    • The site is itself a staging copy.
    • The site is suspended.
    • A staging copy already exists: refresh that one, or delete it first.
    • The requested name starts with www, or already exists on the server.

    Kept out of search results

    Two independent mechanisms, because one of them is advisory.

    WordPress
    blog_public is set to 0 on the copy. Any plugin can undo that, which is why it is not the only measure.
    nginx
    The staging vhost always sends X-Robots-Tag: noindex, nofollow, noarchive. Nothing inside WordPress can remove a header nginx adds.

    Verified on a live pair: the copy sends the header and has blog_public 0 while live has 1.

    Refreshing

    klyrn site staging refresh example.com

    Takes live again and discards everything done on the copy. It reuses the existing staging database rather than creating another, rewrites the addresses back to the staging name, and re-applies the noindex setting.

    wp-config.php is not copied after the first time. That file names the database user and its password, and KLYRN does not store database passwords, so a config that arrived from the other side could not be repaired if it were wrong. It would also carry the other site's authentication salts, which signs out every logged-in user. Both directions exclude it.

    Pushing to live

    klyrn site staging push example.com --confirm example.com
klyrn site staging push example.com --confirm example.com --files-only
klyrn site staging push example.com --confirm example.com --data-only

    You have to type the live domain. Pushing overwrites a production website, and a confirmation you can click through is not a confirmation.

    1. CheckRefuses if neither files nor data were chosen, if the confirmation does not match the live domain, if the live site is suspended, or if a job is already running for it.
    2. Back live upThe real backup engine, not a copy of the directory: the same steps, the same manifest, the same verification. If the backup fails, nothing is changed and the job stops there.
    3. Push the filesrsync with delete, excluding wp-config.php, the caches and .git.
    4. Push the databaseStreamed from one database into the other through a pipe, so the server never needs twice the site's size in free space.
    5. Restore live's identityThe addresses are rewritten from the staging name back to the live name through WP-CLI, so serialised PHP survives, and blog_public is set back to 1: live must not inherit staging's noindex.

    Address rewriting runs three times per push (for https://, http:// and protocol-relative //) with --all-tables --precise, skipping GUIDs.

    Removing a staging copy

    klyrn site delete staging.example.com --remove-files

    A staging copy is an ordinary site, so it is deleted like one. There is no separate command and no separate code path to get wrong.