StageBridge
| 开发者 | emunot |
|---|---|
| 更新时间 | 2026年7月30日 04:52 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPL-2.0+ |
| 版权网址: | 版权信息 |
详情介绍:
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/
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.
- 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.
- 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.
- 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.
安装:
- Upload the
stagebridgefolder to the/wp-content/plugins/directory, or install the ZIP through Plugins > Add New > Upload Plugin. - Activate StageBridge through the Plugins menu in WordPress.
- Go to StageBridge in the admin sidebar.
- Review the settings and exclusions.
- Click Clone to Staging to create your first staging environment.
屏幕截图:
常见问题:
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/
更新日志:
1.7.4-beta5
- Keeps clone file-safety baseline requests within the shared server time budget.
- Checkpoints partial baseline batches so large clones resume without repeating completed files.
- Retries unexplained HTTP 400 responses during clone finalization with a smaller adaptive batch while preserving genuine WordPress error messages.
- Records the exact database table scope inside new backup manifests.
- Restricts restore URL and path normalization to tables that were included in the restored backup.
- Keeps compatibility with older backup manifests while preventing partial backups from expanding into unrelated target tables.
- Saves staging identity before expensive final metadata work.
- Builds clone file conflict baselines from the existing clone file lists in resumable slices.
- Builds database row and content-object conflict baselines in checkpointed batches.
- Resumes final metadata work after temporary server errors instead of restarting it.
- Disables clone, sync, push, and backup actions until file sizes, large-file warnings, table sizes, and saved exclusions finish loading.
- Prevents operations from bypassing the safety selector if its interface is unavailable.
- Restricts clone URL replacement and safety baselines to tables successfully cloned from the user's checked selection.
- Restricts sync database baselines to the tables checked for that sync.
- Keeps excluded files outside clone file baselines by reusing the filtered transfer and reconciliation lists.
- Makes clone, sync, push, backup, restore, and database export work in shorter resumable steps.
- Adapts retries and batch sizes when a server slows down or returns a temporary error.
- Adds configurable large-file and large-table thresholds with clear warned opt-ins.
- Keeps essential WordPress content, configuration, taxonomy, comment, and user tables selected regardless of size.
- Remembers unchecked files, folders, and database tables separately for each operation.
- Adds database-table selection to clone and records omitted files and tables in backup manifests.
- Makes file backups adapt to elapsed time, source bytes, and observed server throughput.
- Avoids recompressing media and archive formats that are already compressed.
- Splits file backups into bounded multipart ZIP archives and restores them in resumable steps.
- Retains restore support for backups created with the earlier single
files.zipformat.
- Speeds up Smart Push and sync by using persistent file inventory caches, baseline-aware database planning, and cheaper file-change checks.
- Improves generated-file catch-up after clone, sync, and push without relying on plugin-specific folders.
- Speeds up URL and path replacement by skipping tables that do not contain staging references.
- Makes Smart Push content detection more reliable when the lightweight change journal is incomplete.
- Adds a Stop Operation control for clearing stale StageBridge locks from long-running operation modals.
- Improves progress modal behavior with smoother phase pills and persistent gradient fills.
- Fixes pre-push safety backup handoff for subdomain staging environments.
- Adds a restore confirmation modal with an enabled-by-default safety backup option.
- Shows the exact restore target environment and names pre-restore safety backups by environment.
- Keeps restore progress visually continuous from safety backup through final restore.
- Hardened Smart Push three-way conflict tracking so preserved production changes remain protected on later pushes.
- Preserves independent production pages while pushing unrelated staging pages, including same-ID content collisions by inserting staging content with a new production ID.
- Protects StageBridge runtime state/log tables from push, sync, backup export, and restore import so backup records and operation locks are not overwritten as site content.
- Increased long-operation request tolerance and shortened abandoned-operation recovery so large sync/push jobs do not retry into their own active locks.
- Makes restore resumable and validates backup integrity before changing the target site.
- Enforces strict files-only/database-only push scope and aborts when staging changes after planning.
- Hardens Smart Push content identity, persistent ID mapping, table activation, and file-copy failure handling.
- Made file preview and execution share the same plan, including safe handling for files independently created at the same path.
- Added owned push locks, per-step mutexes, heartbeats, stale-lock recovery, idempotent tokens, and interrupted-job resumption.
- Split changed-file copies and smart database work into resumable batches and moved large database baselines out of WordPress options.
- Added per-content change journaling so posts, pages, products, metadata, and terms can be checked individually without repeatedly scanning every content item.
- Added strict transactional content writes, destination-safe post and taxonomy ID mapping, deletion propagation, cache clearing, and post-push health checks.
- Added schema-aware table planning, last-second production rechecks, failed-swap rollback, and successful snapshot cleanup.
- Expanded live-data protection to users, comments, sessions, cron, transients, security runtime data, WooCommerce coupon usage, and product lookup data.
- Reconciled changed existing generated assets as well as missing files, and made failed planned copies stop the operation.
- Refreshed the database portion of full safety backups after production is locked for a consistent pre-push restore point.
- Keeps environment bootstrap files isolated, cleans up failed backup/clone jobs, and improves push confirmation accessibility.
- 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.
- 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
keyrestore 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.
- 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.
- 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.
- 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.
- Escaped remaining dashboard output values that were safe but not scanner-friendly.
- Replaced direct unserialize warning suppression with a small guarded unserialize helper.
- Replaced generated-asset warmup requests with wp_safe_remote_get(), safe URL sanitization, and default SSL verification.
- 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.
- 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.
- Removed uploads-derived site-root guessing and routed root detection through WordPress-native helpers.
- Loaded the WordPress filesystem API from the detected site root.
- 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.
- Fixed the Backups page variable mismatch that could make existing backups appear as empty.
- Fixed completed operation modals sometimes showing a partially-filled main progress bar despite reporting 100%.
- Reduced phase pill text to 9px.
- Changed phase pill progress fills to green.
- Reduced progress modal text sizes for a cleaner, denser layout.
- Removed the visible focus rectangle from the live log toggle.
- 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.
- Refined operation progress modals with compact filled phase pills.
- Collapsed live activity logs by default while keeping log lines available on demand.
- 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.
- 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.
- Corrected the clone progress checklist count after adding the file reconciliation step.
- 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.
- 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.
- Reverted before release in favor of diagnostic tracing.
- Added an initial generated frontend asset repair pass for sync. Superseded by diagnostic tracing.
- 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.
- 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.
- 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.
- Made URL/path replacement idempotent when the replacement contains the search value, preventing staging paths from being repeatedly expanded during clone.
- Fixed staging diagnostic setup so the endpoint uses the configured staging path before reading debug information.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Reset temporary server error retry counters after successful recovered requests across clone, sync, push, backup, restore, and delete operations.
- 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.
- Hid the staging folder field when creating a subdomain staging environment.
- Reused the subdomain prefix as the staging document-root folder name internally.
- Fixed the Create Staging dashboard button so it opens the modal reliably.
- Replaced the inline first-time staging form with a centered create-staging modal.
- Added a segmented Subfolder/Subdomain toggle for staging creation.
- 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.
- 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.
- 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.
- Fixed boolean request parsing so unchecked force overwrite stays disabled during push.
- Removed optional plugin website metadata to satisfy WordPress.org submission requirements.
- Updated public plugin naming and WordPress.org compatibility metadata. For older release notes, see changelog.txt in the plugin package.