WPHammer
Log in
  • When to refresh
  • What refresh does not do
  • Status during refresh
  • Related

    • Syncing Staging

    After a staging environment has been running for a while, its data drifts from production — new content, updated plugins, configuration changes. WPHammer's refresh operation pulls the latest production state into staging so you are testing against current data.

    How refresh works

    Refreshing a staging environment dispatches the RefreshStagingPipeline — a five-step deployment that replaces the staging data with a fresh copy from production while preserving the staging configuration and protections.

    1. Truncate staging database

    The TruncateStagingDatabaseJob runs wp db reset --yes to clear the existing staging database. This removes all tables so the subsequent clone starts from a clean state.

    2. Copy site files

    The CopyStagingFilesJob uses rsync over SSH to copy current production files to the staging subdirectory. This is the same job used during staging creation — it respects the configured media mode (copy, skip, or symlink) and excludes .git and the staging directory itself.

    3. Configure WordPress

    The ConfigureStagingWpJob re-applies the staging WordPress configuration:

    • Staging database credentials
    • WP_ENVIRONMENT_TYPE set to staging
    • DISABLE_WP_CRON set to true
    • WP_HOME and WP_SITEURL pointed to the staging URL

    This step ensures that even if production's wp-config.php changed, staging retains its own isolated configuration.

    4. Clone database

    The CloneStagingDatabaseJob exports the production database, imports it into the freshly reset staging database, and runs the URL search-replace to convert production URLs to staging URLs. It sets blog_public to 0 and flushes all caches.

    5. Apply protections

    The ApplyStagingProtectionsJob re-installs all staging safeguards — robots.txt, email blocking mu-plugin, admin banner mu-plugin, and the wp-cli-login plugin. The staging status returns to Active and last_synced_at is updated.

    When to refresh

    Refresh staging when:

    • Production content has changed significantly — new posts, updated pages, or changed settings that your staging testing depends on
    • Production plugins or themes were updated — your staging should test against the current code base
    • You finished a round of staging changes and want to start fresh with a clean production copy
    • Before a push to production — to verify your changes still work against the latest production state

    What refresh does not do

    • Nginx configuration is not re-created — the location block and FPM socket configuration set during creation remain in place
    • The staging database and user are not re-created — the existing Forge database is reused (just truncated and re-populated)
    • HTTP Basic Auth rules are preserved — security rules are not modified during refresh

    Status during refresh

    While refreshing, the staging status is set to Refreshing (amber indicator). The isBusy() method returns true, which prevents other operations (push, delete, another refresh) from running concurrently.

    If the refresh fails at any step, the staging status is set to Failed. You can retry the refresh or investigate the deployment pipeline steps to identify the failure point.

    Related