WPHammer
Log in
  • Status during push
  • Best practices
  • What does not get pushed
  • Related

    • Pushing to Production

    When your staging changes are ready, WPHammer can push them to the production site. The push operation supports selective sync — you can push files only, database only, or both — and specific table filtering for granular control. A pre-push backup is always created so you can roll back if needed.

    Push options

    Before pushing, you choose what to sync:

    • Sync files — rsync staging files to production, replacing production files with staging versions
    • Sync database — export the staging database and import it into production
    • Sync tables — when syncing the database, optionally limit the sync to specific tables (e.g., only push wp_options and wp_posts while leaving wp_users untouched)

    You can enable files, database, or both. Table filtering is only available when database sync is enabled.

    What the push pipeline does

    The PushStagingPipeline runs five steps:

    1. Backup production

    The BackupProductionJob creates a safety backup before any changes:

    • Exports the production database to /tmp/pre-push-backup.sql
    • Creates a tar.gz archive of production files (excluding the staging directory)

    This backup is cleaned up after the push completes, but provides a rollback path if the push causes problems.

    2. Sync files

    The SyncStagingFilesJob uses rsync over SSH to copy staging files to the production directory. This step is skipped if file sync was not selected.

    Key exclusions during file sync:

    • wp-config.php — production keeps its own database credentials and configuration
    • robots.txt — staging's Disallow: / must not overwrite production's robots file
    • Staging mu-plugins (staging-disable-mail.php, staging-admin-banner.php) — staging-specific plugins are not pushed
    • The staging subdirectory itself

    The rsync uses a delete flag, meaning files that exist in production but not in staging are removed. This ensures production exactly matches staging after the push.

    3. Sync database

    The SyncStagingDatabaseJob handles database migration. This step is skipped if database sync was not selected.

    • Full sync — exports the entire staging database and imports it into production
    • Selective sync — when specific tables are selected, only those tables are exported from staging and imported into production

    4. Search-replace URLs

    The SearchReplaceProductionJob reverses the URL transforms that were applied when staging was created. Staging URLs (e.g., yourdomain.com/staging-dir) are replaced with production URLs (e.g., yourdomain.com) across all database tables using wp search-replace.

    This step is skipped if no database was synced (since there are no staging URLs to replace in that case).

    5. Flush caches

    The FlushProductionCacheJob completes the push:

    • Runs wp cache flush to clear the WordPress object cache
    • Runs wp rewrite flush to regenerate permalink rules
    • Removes the pre-push backup files (/tmp/pre-push-backup.sql and the file archive)
    • Updates the staging status back to Active

    Status during push

    While pushing, the staging status is set to Pushing (amber indicator). The isBusy() method returns true, preventing concurrent operations on the same staging environment.

    If the push fails at any step, the staging status is set to Failed. The pre-push backup files remain on the server so you can manually recover if needed.

    Best practices

    • Refresh staging first — before pushing, consider refreshing staging to verify your changes work against the latest production data
    • Use selective table sync — if you only changed content (posts, pages), push just the relevant tables to avoid overwriting user data or plugin settings
    • Create a snapshot — for extra safety, create a snapshot before pushing. The pipeline creates its own backup, but a snapshot gives you a one-click rollback
    • Test after pushing — verify the production site after the push. Check key pages, forms, and functionality to confirm everything transferred correctly

    What does not get pushed

    The following are intentionally excluded from the push:

    • wp-config.php — production keeps its own database credentials, environment type, and cron settings
    • robots.txt — production's SEO configuration is preserved
    • Staging mu-plugins — the email blocking and admin banner plugins stay in staging only
    • The staging directory itself — the staging subdirectory is not copied into production

    Related