Title: StageBridge
Author: Daniel Emunot
Published: <strong>18 de juny de 2026</strong>
Last modified: 24 de juny de 2026

---

Cerca extensions

![](https://ps.w.org/stagebridge/assets/banner-772x250.png?rev=3583661)

![](https://ps.w.org/stagebridge/assets/icon.svg?rev=3576616)

# StageBridge

 Per [Daniel Emunot](https://profiles.wordpress.org/emunot/)

[Baixa](https://downloads.wordpress.org/plugin/stagebridge.1.7.0.zip)

 * [Detalls](https://ca.wordpress.org/plugins/stagebridge/#description)
 * [Ressenyes](https://ca.wordpress.org/plugins/stagebridge/#reviews)
 *  [Instal·lació](https://ca.wordpress.org/plugins/stagebridge/#installation)
 * [Desenvolupament](https://ca.wordpress.org/plugins/stagebridge/#developers)

 [Suport](https://wordpress.org/support/plugin/stagebridge/)

## Descripció

**Push tested changes. Keep live work.**

StageBridge is a WordPress staging plugin built around Smart Push. It checks what
changed in staging and on your live site, moves the staging work it can safely apply,
and keeps unrelated production work in place.

That means a new production page does not need to block an unrelated staging page
from going live. The same protection works at the individual post, page, and custom-
post level, while changed production files are protected from conflicting staging
copies.

For WooCommerce stores, Smart Push also keeps live orders, customers, stock, carts,
sessions, webhooks, scheduled actions, and payment settings on production.

Documentation:
 [https://emunot.com/stagebridge/](https://emunot.com/stagebridge/)

**Why Smart Push Matters**

A staging site can become outdated while customers, editors, or clients continue
working on production. A full overwrite can replace that newer live work. Smart 
Push compares both environments and applies non-conflicting staging changes while
preserving unrelated production changes.

You stay in control:

 * Preview file and database changes before starting.
 * Push files, database data, or both.
 * Keep the automatic safety backup enabled or skip it for a small follow-up operation.
 * Use Force Overwrite only when staging should intentionally replace matching production
   data.

**WooCommerce Protection**

When WooCommerce is detected, StageBridge protects active store data during Smart
Push:

 * Live orders, including HPOS order data.
 * Customers, stock, carts, and sessions.
 * Payment settings, webhooks, and scheduled actions.
 * Staging email delivery, WooCommerce webhooks, and Action Scheduler processing
   are paused by default.

Product content, prices, categories, tags, plugin updates, and theme changes can
still move to production when they do not conflict with protected live data.

**Complete Staging Workflow**

 * **Clone** – Create a staging copy of your production site in a configurable subfolder,
   such as /staging/, or on a staging subdomain such as staging.example.com.
 * **Sync** – Pull current production files and database changes into staging.
 * **Smart Push** – Push staging changes without losing unrelated work added to 
   your live site.
 * **WooCommerce protection** – Keep live orders and active store data on production
   during Smart Push.
 * **Force overwrite** – Optional push mode for cases where staging should intentionally
   replace production changes.
 * **Backups** – Create full, database-only, or files-only backups manually or on
   a schedule.
 * **Restore** – Restore from saved backups when you need to roll back.

**Additional Features**

 * Incremental file copying for clone, sync, and push operations.
 * Conflict-aware push protection for production files and common WordPress content
   tables.
 * Compressed file backups to reduce inode usage.
 * Disposable security, traffic, scan, and cache tables are excluded from backups
   by default while remaining manually selectable.
 * Automatic full safety backups before sync and push, with a per-operation checkbox
   to skip them when appropriate.
 * Subfolder or subdomain staging URL modes.
 * Staging admin bar indicator and frontend staging banner.
 * Same-tab switch buttons to reduce accidental editing in the wrong environment.
 * Search/replace for URLs and paths with serialized data support.
 * Password-protect staging with .htaccess / .htpasswd when supported by the server.
 * robots.txt handling for staging environments.
 * Email notifications for clone, sync, push, and backup events.
 * Live activity logs and persistent completion modals for long-running operations.
 * Configurable file exclusions for cache, backup, archive, and log files.
 * Automatic retries for temporary server errors.
 * Clean uninstall that removes plugin options and custom plugin tables.

StageBridge is intended for site owners, maintainers, and developers who need a 
practical staging workflow from inside WordPress.

### Requirements

 * WordPress 6.2 or higher
 * PHP 7.4 or higher
 * ZipArchive PHP extension for file and full backups
 * mod_rewrite for optional staging password protection on Apache-compatible servers
 * Sufficient disk space for staging copies and backups

### Privacy

StageBridge runs locally inside your WordPress installation. It does not send site
data to an external service.

The plugin stores settings, logs, backup metadata, operation progress, and staging
metadata in the WordPress database. Backup archives and temporary job files are 
stored on your server under wp-content/uploads/stagebridge/. Email notifications
are sent through your WordPress site’s configured mail system.

## Captures

[⌊Manage production and staging from one clear dashboard.⌉⌊Manage production and
staging from one clear dashboard.⌉[

Manage production and staging from one clear dashboard.

[⌊Follow every long-running operation with phase progress and live logs.⌉⌊Follow
every long-running operation with phase progress and live logs.⌉[

Follow every long-running operation with phase progress and live logs.

[⌊Smart Push is recommended by default and protects WooCommerce store activity.⌉⌊
Smart Push is recommended by default and protects WooCommerce store activity.⌉[

Smart Push is recommended by default and protects WooCommerce store activity.

[⌊Create compressed backups and restore or delete them in bulk.⌉⌊Create compressed
backups and restore or delete them in bulk.⌉[

Create compressed backups and restore or delete them in bulk.

[⌊Configure staging, exclusions, retries, backups, and notifications.⌉⌊Configure
staging, exclusions, retries, backups, and notifications.⌉[

Configure staging, exclusions, retries, backups, and notifications.

[⌊Preview staging changes, production conflicts, and protected live store data before
pushing.⌉⌊Preview staging changes, production conflicts, and protected live store
data before pushing.⌉[

Preview staging changes, production conflicts, and protected live store data before
pushing.

## Instal·lació

 1. Upload the `stagebridge` folder to the `/wp-content/plugins/` directory, or install
    the ZIP through **Plugins > Add New > Upload Plugin**.
 2. Activate StageBridge through the **Plugins** menu in WordPress.
 3. Go to **StageBridge** in the admin sidebar.
 4. Review the settings and exclusions.
 5. Click **Clone to Staging** to create your first staging environment.

## PMF

### What is Smart Push?

Smart Push compares staging with production and pushes non-conflicting staging changes
while preserving unrelated live-site work. Posts, pages, and custom post types are
evaluated individually instead of treating the entire content table as one change.

### Does StageBridge push every production table and file by default?

No. Sync and push operations compare files and database data so unchanged items 
can be skipped. Smart Push is the default and tries to preserve production changes
made since the last clone, sync, or push.

### How does StageBridge protect WooCommerce stores?

During Smart Push, StageBridge keeps live orders, customers, stock, carts, sessions,
payment settings, webhooks, and scheduled actions on production. Force Overwrite
requires separate confirmation before it can replace protected live store data.

### Can I force staging to overwrite production?

Yes. Push includes an explicit force overwrite option with a warning. Use it only
when you are sure staging should replace matching production files and database 
data.

### Are backups compressed?

Yes. File and full backups store site files in a ZIP archive when the PHP ZipArchive
extension is available.

### Does the plugin protect staging from search engines?

StageBridge writes staging support files, including robots handling, so staging 
copies are discouraged from being indexed.

### Can I change the staging folder after staging has been created?

The staging folder and URL type settings are locked while a staging environment 
exists. Delete staging first if you need to recreate it in a different folder or
switch between subfolder and subdomain staging.

### Can StageBridge create DNS records or hosting subdomains?

No. If you choose subdomain staging, create the subdomain in your hosting panel 
first and point its document root to the staging folder configured in StageBridge.

### Will this work on every host?

StageBridge is designed for standard WordPress hosting, but very large sites can
still be limited by hosting CPU, disk, memory, request timeout, or firewall rules.
The plugin includes retry and pacing safeguards, but reliable backups are still 
recommended before major operations.

### Where can I find the full documentation?

You can read the full StageBridge documentation here:
 [https://emunot.com/stagebridge/](https://emunot.com/stagebridge/)

## Ressenyes

No hi ha ressenyes per a aquesta extensió.

## Col·laboradors i desenvolupadors

«StageBridge» és programari de codi obert. La següent gent ha col·laborat en aquesta
extensió.

Col·laboradors

 *   [ Daniel Emunot ](https://profiles.wordpress.org/emunot/)

[Traduïu «StageBridge» a la vostra llengua.](https://translate.wordpress.org/projects/wp-plugins/stagebridge)

### Interessats en el desenvolupament?

[Navegueu pel codi](https://plugins.trac.wordpress.org/browser/stagebridge/), baixeu-
vos el [repositori SVN](https://plugins.svn.wordpress.org/stagebridge/), o subscriviu-
vos al [registre de desenvolupament](https://plugins.trac.wordpress.org/log/stagebridge/)
per [fisl de subscripció RSS](https://plugins.trac.wordpress.org/log/stagebridge/?limit=100&mode=stop_on_copy&format=rss).

## Registre de canvis

#### 1.7.0

 * Detects WooCommerce stores and HPOS order storage.
 * Protects live orders, customers, stock, sessions, payment credentials, webhooks,
   and scheduled-action data during Smart Push.
 * Preserves production stock and review visibility independently while allowing
   non-conflicting staging product content, prices, categories, and tags to move
   live.
 * Adds separate explicit consent before Force Overwrite can include live WooCommerce
   data.
 * Marks clones with WordPress’s staging environment type and preserves Woo Subscriptions
   production identity.
 * Blocks staging email and WooCommerce webhook delivery by default.
 * Pauses Action Scheduler queue processing on staging by default, with settings
   to control each staging safeguard.
 * Shows WooCommerce and HPOS protection in push preview, confirmation, activity
   logs, and reports.
 * Refreshes WooCommerce product caches and lookup data after merged product updates
   without relying on private WooCommerce cache classes.
 * Keeps restore state across split SQL parts and prepares target tables safely 
   before their first restored row.
 * Locks the target environment during restore and refreshes that lock during long
   database imports.
 * Uses restore-safe row replacement so backup values win over concurrently recreated
   unique-key rows.
 * Prevents progress writes from changing a partially restored options table and
   refreshes WordPress caches after restoration.

#### 1.6.32

 * Excludes known disposable Wordfence, Action Scheduler, Rank Math, and Redirection
   log/cache tables from backups by default.
 * Keeps configuration, security settings, and Wordfence 2FA tables selected for
   backup.
 * Shows default table exclusions in the database selector and allows users to include
   them manually with Select All or individual checkboxes.
 * Applies the same default table selection to manual, scheduled, and pre-operation
   safety backups.
 * Quotes every exported database column identifier so reserved names such as `key`
   restore correctly on MySQL and MariaDB.
 * Repairs the short-lived unquoted StageBridge export format during import, keeping
   already-created backups restorable.
 * Shortens database export activity messages so long backups do not flood the live
   log with large table lists.

#### 1.6.31

 * Preserves literal percent signs and URL-encoded data exactly during database 
   backup export.
 * Recovers WordPress database placeholder tokens from affected backups when they
   are restored.
 * Uses deterministic row ordering and explicit column lists for more reliable database
   exports.
 * Stops restore immediately on a database import error instead of continuing with
   partially restored data.
 * Safely normalizes site URLs and filesystem paths when a backup is restored into
   its environment.
 * Updates the restore modal with compact phases for files, database, site-data 
   normalization, and completion.
 * Improves SQL statement parsing for quoted values and SQL comments.

#### 1.6.30

 * Fixes staging-side operations on subdomain staging environments by using the 
   correct admin request URLs and persisting normalized staging environment settings
   after clone and sync.
 * Adds a final generated-file pass during push so late-created frontend assets 
   such as generated CSS files are copied to production before the push completes.
 * Keeps sync and push inside one continuous progress modal when a safety backup
   runs first, and makes the main progress bar reflect the full multi-step operation
   instead of jumping to 100% too early.

#### 1.6.29

 * Reworked backup finalization into resumable phases for database export, manifest
   writing, and cleanup.
 * Added adaptive backup finish batching so healthy servers move quickly and overloaded
   servers automatically back off.
 * Replaced repeated whole-file SQL append behavior with WordPress-filesystem-friendly
   SQL part files and restore support for multi-part database backups.
 * Improves smart push for posts, pages, and custom post types so new staging content
   can still be pushed when production has unrelated new content with the same numeric
   ID.
 * Matches existing content objects by stable identity as well as baseline ID, reducing
   false conflicts after prior safe pushes.
 * Inserts colliding new staging content as new production posts instead of skipping
   the change entirely.

#### 1.6.28

 * Escaped remaining dashboard output values that were safe but not scanner-friendly.
 * Replaced direct unserialize warning suppression with a small guarded unserialize
   helper.

#### 1.6.27

 * Replaced generated-asset warmup requests with wp_safe_remote_get(), safe URL 
   sanitization, and default SSL verification.

#### 1.6.26

 * Removed the custom server-root fallback and kept site-root detection on WordPress-
   native get_home_path().
 * Converted uninstall cleanup and custom table creation to validated/prepared SQL
   identifiers.
 * Fixed a staging diagnostic query to use a prepared table identifier.

#### 1.6.25

 * Removed remaining raw local file read fallback from StageBridge helpers.
 * Replaced the remaining raw directory removal path with WordPress filesystem API
   removal.
 * Centralized local file writes through the WordPress filesystem API.

#### 1.6.24

 * Removed uploads-derived site-root guessing and routed root detection through 
   WordPress-native helpers.
 * Loaded the WordPress filesystem API from the detected site root.

#### 1.6.23

 * Replaced uploads-path root inference with WordPress-native root detection.
 * Routed file copy/timestamp preservation through the WordPress filesystem API 
   with destination-root guards.
 * Converted dynamic SQL identifiers to wpdb::prepare() %i placeholders and raised
   the minimum WordPress version to 6.2.

#### 1.6.22

 * Fixed the Backups page variable mismatch that could make existing backups appear
   as empty.

#### 1.6.21

 * Fixed completed operation modals sometimes showing a partially-filled main progress
   bar despite reporting 100%.

#### 1.6.20

 * Reduced phase pill text to 9px.
 * Changed phase pill progress fills to green.

#### 1.6.19

 * Reduced progress modal text sizes for a cleaner, denser layout.
 * Removed the visible focus rectangle from the live log toggle.

#### 1.6.18

 * Moved the main operation progress bar above the phase pills.
 * Added the current step subtitle to the progress modal header.
 * Tightened phase pill sizing and made the main percentage reflect overall phase
   completion.

#### 1.6.17

 * Refined operation progress modals with compact filled phase pills.
 * Collapsed live activity logs by default while keeping log lines available on 
   demand.

#### 1.6.16

 * Added a final generated-file safety pass to sync, warming production/staging 
   once and copying only missing included files after staging config is written.
 * Updated the sync progress checklist to show the generated-file check and metadata
   steps clearly.

#### 1.6.15

 * Added a final generated-file check after staging config is written, copying only
   missing files so staging config/runtime files are not overwritten.
 * Warmed production and staging front pages once during clone finalization so generated
   frontend assets can be created before the final missing-file copy.

#### 1.6.14

 * Corrected the clone progress checklist count after adding the file reconciliation
   step.

#### 1.6.13

 * Added a final clone file reconciliation pass to copy included files that appear
   or change after the initial clone scan, preventing late-generated frontend assets
   from being missed.

#### 1.6.12

 * Added authenticated staging file diagnostics for tracing source/staging file 
   existence, exclusion status, baseline presence, and missing-file examples.
 * Removed the broad missing-file repair attempt so diagnostics can reveal the actual
   cause instead of hiding the symptom.

#### 1.6.11

 * Reverted before release in favor of diagnostic tracing.

#### 1.6.10

 * Added an initial generated frontend asset repair pass for sync. Superseded by
   diagnostic tracing.

#### 1.6.9

 * Added default-enabled safety backup checkboxes to sync and push flows so users
   can skip pre-operation backups for small repeat operations.
 * Clarified sync and push logs when a pre-operation safety backup is skipped by
   user choice.

#### 1.6.8

 * Moved push file-baseline manifests out of the database option row and into protected
   files under wp-content/uploads/stagebridge/baselines.
 * Kept only compact baseline metadata in the WordPress option to avoid large database
   payloads on sites with many files.

#### 1.6.7

 * Removed PHP timeout adjustments and aligned the minimum WordPress version with
   the WordPress APIs used by StageBridge.
 * Tightened autologin request sanitization for Plugin Check compatibility.

#### 1.6.6

 * Made URL/path replacement idempotent when the replacement contains the search
   value, preventing staging paths from being repeatedly expanded during clone.

#### 1.6.5

 * Fixed staging diagnostic setup so the endpoint uses the configured staging path
   before reading debug information.

#### 1.6.4

 * Fixed remaining StageBridge bootstrap references after renaming the main plugin
   instance function.
 * Removed the old autologin token compatibility alias so public hooks and request
   parameters consistently use the StageBridge prefix.
 * Re-verified unique StageBridge-prefixed functions, classes, constants, options,
   hooks, and AJAX actions.

#### 1.6.3

 * Reworked runtime path handling to use StageBridge helpers built on WordPress 
   path and uploads directory APIs.
 * Replaced legacy .htpasswd SHA-1 staging password hashes with bcrypt hashes.
 * Removed dynamic WordPress role option writes during staging auto-login repair.
 * Replaced remaining direct local file reads with StageBridge local file helpers
   or wp_json_file_decode().
 * Removed fopen/fwrite/fclose from SQL backup export.
 * Centralized local file writes through StageBridge helper functions.
 * Added strict SQL identifier validation and quoting for dynamic WordPress table
   and column queries used by clone, sync, push, backup, and restore.
 * Removed private-build migration and data-repair compatibility routines that are
   not needed before public release.

#### 1.6.2

 * Moved backup archives and manifests to wp-content/uploads/stagebridge/backups
   instead of storing runtime backup data in the plugin directory.
 * Removed the automatic admin_init plugin-code sync routine that copied StageBridge
   code into the staging plugin folder.
 * Confirmed remaining STAGEBRIDGE_PLUGIN_DIR usage is limited to loading static
   plugin files and admin views.

#### 1.6.1

 * Clone URL replacement now shows the current table name in the progress modal 
   instead of only the table number.
 * Clone URL replacement now skips known high-volume operational log, traffic, and
   security scan tables that do not need staging URL conversion.
 * Existing in-progress clone jobs remap their URL replacement table index safely
   when operational tables are filtered out.

#### 1.6.0

 * Optimized URL and path replacement to select only rows that contain the old URL
   or path before loading and updating data.
 * Sync now limits URL and path replacement to database tables that were actually
   cloned from production.
 * Push now limits URL and path replacement to non-content tables that were safely
   swapped into production.

#### 1.5.0

 * Added baseline-first smart file planning for push and sync. When a file baseline
   exists, StageBridge uses size and modified time to find changed files before 
   copying.
 * Changed new file baselines to store cheap size/mtime signatures instead of hashing
   every file during baseline refresh.
 * Push now copies only planned changed files when a reliable baseline exists, while
   still detecting and skipping production file conflicts.
 * Sync now copies only planned changed files when a reliable baseline exists and
   removes stale staging files from the same baseline.
 * Smart push now narrows WordPress content-object checks to posts/pages/custom 
   post types changed since the baseline, plus deleted content IDs.
 * Custom database tables with a primary key and timestamp column now use candidate
   row detection before falling back to exact row-signature comparison.

#### 1.4.4

 * Added individual mini progress bars for each checklist step in clone, backup,
   sync, and push modals.
 * Kept the main operation progress bar as the overall progress indicator while 
   each active step now has its own local progress.
 * Unified pre-sync and pre-push safety backups with the main StageBridge backup
   directory so they appear in the backup list.
 * Hardened backup-store exclusions so file compare/copy operations skip both current
   and legacy backup paths.

#### 1.4.3

 * Renamed push and sync file phases to clarify that StageBridge compares files 
   first and only copies changed files.
 * Renamed push database phases to reflect smart row/content application rather 
   than whole-table-only pushing.
 * Improved push activity reports with checked-file counts, changed-file counts,
   preserved content, conflicts, and untracked-table skips.

#### 1.4.2

 * Removed optional author website metadata because the previous URL returned a 
   404 during review.
 * Changed author display name to Daniel Emunot.
 * Moved clone and backup file-list job payloads out of transients and into protected
   temporary files under uploads/stagebridge/jobs.

#### 1.4.1

 * Added object-level smart push for WordPress content so pages, posts, and custom
   post types are compared independently instead of only at table level.
 * Content-object push now evaluates each post together with its post meta and term
   relationships, preserving unrelated production edits while allowing non-conflicting
   staging edits through.
 * Revision and auto-draft rows are ignored during object-level push to avoid noisy
   conflicts from WordPress autosaves and edit history.
 * New row/object conflict baselines are created during clone, sync, and push baseline
   refreshes. Run a fresh sync after updating to create the new object-level baseline
   before relying on this protection.

#### 1.3.88

 * Replaced the generated autologin bridge file with a WordPress admin-post endpoint.
 * Moved StageBridge backup and autologin storage under the uploads directory.
 * Removed filesystem memory-limit overrides and normalized root path handling in
   flagged file-operation paths.

#### 1.3.87

 * Reset temporary server error retry counters after successful recovered requests
   across clone, sync, push, backup, restore, and delete operations.

#### 1.3.86

 * Added dynamic root-level exclusions so backups, clone, sync, push, previews, 
   and baselines skip unrelated folders inside the WordPress root.
 * Excluded common archive/export files such as ZIP, TAR, GZ, SQL, and WPress files
   by default.
 * Updated file selection summaries to use the same automatic exclusions as operations.

#### 1.3.85

 * Hid the staging folder field when creating a subdomain staging environment.
 * Reused the subdomain prefix as the staging document-root folder name internally.

#### 1.3.84

 * Fixed the Create Staging dashboard button so it opens the modal reliably.

#### 1.3.83

 * Replaced the inline first-time staging form with a centered create-staging modal.
 * Added a segmented Subfolder/Subdomain toggle for staging creation.

#### 1.3.82

 * Added support for creating staging environments as either a subfolder or a subdomain.
 * Added staging URL type and subdomain settings, locked after staging is created.
 * Updated clone, sync, push, backups, autologin, and staging metadata handling 
   for subdomain staging URLs.

#### 1.3.81

 * Completed StageBridge slug, function, action, option, class, and asset-prefix
   refactor.
 * Removed optional wp-config repair and debug-writing routines.
 * Improved plugin and autologin path resolution.

#### 1.3.80

 * Renamed the public plugin identity to StageBridge.
 * Moved staging toolbar CSS to WordPress enqueue APIs.
 * Removed inline settings-page JavaScript.
 * Sanitized decoded JSON request arrays recursively.

#### 1.3.79

 * Fixed boolean request parsing so unchecked force overwrite stays disabled during
   push.

#### 1.3.78

 * Removed optional plugin website metadata to satisfy WordPress.org submission 
   requirements.

#### 1.3.77

 * Updated public plugin naming and WordPress.org compatibility metadata.

For older release notes, see changelog.txt in the plugin package.

## Meta

 *  Versió **1.7.0**
 *  Darrera actualització **fa 2 dies**
 *  Instal·lacions actives **Menys de 10**
 *  Versió del WordPress ** 6.2 o posterior **
 *  Provada fins a **7.0**
 *  Versió del PHP ** 7.4 o posterior **
 *  Idioma
 * [English (US)](https://wordpress.org/plugins/stagebridge/)
 * Etiquetes
 * [backup](https://ca.wordpress.org/plugins/tags/backup/)[clone](https://ca.wordpress.org/plugins/tags/clone/)
   [deployment](https://ca.wordpress.org/plugins/tags/deployment/)[development](https://ca.wordpress.org/plugins/tags/development/)
   [staging](https://ca.wordpress.org/plugins/tags/staging/)
 *  [Vista avançada](https://ca.wordpress.org/plugins/stagebridge/advanced/)

## Valoracions

Encara no s'ha enviat cap ressenya.

[Your review](https://wordpress.org/support/plugin/stagebridge/reviews/#new-post)

[Visualitzeu totes les ressenyes](https://wordpress.org/support/plugin/stagebridge/reviews/)

## Col·laboradors

 *   [ Daniel Emunot ](https://profiles.wordpress.org/emunot/)

## Suport

Teniu quelcom a dir? Necessiteu ajuda?

 [Visualitza els fòrums de suport](https://wordpress.org/support/plugin/stagebridge/)