Preview and Staging

Preview and Staging are separate workflows designed for different jobs.

Preview

Preview exposes the existing managed site through a temporary preview-...webcore.cloud hostname. It does not create a second WordPress installation and it does not rewrite the stored production URL in the database.

Where required, Webcore rewrites production URLs in text responses, suppresses outgoing WordPress mail and marks Preview responses as noindex.

Use Preview when production DNS still points elsewhere or when you need to inspect the exact managed installation before cutover.

Preview is also useful for WP Admin one-click access before the production hostname and certificate are usable from the new hosting node.

Staging

Staging is a separate same-node WordPress site with its own system user, files, database and Webcore hostname. It is intended for changes that must not affect production until they have been tested.

The staging clone is protected by default:

• outgoing WordPress mail is suppressed
• WP-Cron is disabled
• WP_ENVIRONMENT_TYPE is set to staging
• blog_public is set to 0
• Webcore page cache is disabled for the staging copy
• cloned caches and transients are flushed

Nested staging sites are not supported.

Refresh from Live

Refresh from Live replaces the staging files and database with the current production state. Webcore creates a staging safety snapshot before replacement.

If the refresh fails, the previous staging state is restored automatically where possible. After a successful refresh, staging-specific URL rewriting and safety protections are reapplied.

Push to Live

Push to Live promotes the complete staging files and database to production. Before the copy starts, Webcore creates a production safety snapshot.

If the push fails, the Panel attempts to restore the previous production files and database automatically.

Because this is a full-copy workflow, changes made directly on production after staging was created can be replaced by a later push. Refresh Staging from Live first when production has received important newer changes that must be preserved.

Snapshots

Manual and automatic staging snapshots contain both the site files and a MariaDB dump. They can be restored or permanently deleted from the Staging page.

Production safety snapshots are retained separately for rollback around a staging push. Treat them as short-term operational safety points rather than a replacement for the site's normal backup policy.

Choosing Preview or Staging

Use Preview when you want to inspect the production installation through an alternate hostname without cloning it.

Use Staging when you need an independent writable copy for plugin/theme changes, application testing, backup validation or other work that must be isolated from production.