StageBridge
| 开发者 | emunot |
|---|---|
| 更新时间 | 2026年6月24日 02:40 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPL-2.0+ |
| 版权网址: | 版权信息 |
详情介绍:
StageBridge gives you a complete staging workflow without leaving WordPress.
Smart Push checks what changed in staging and on your live site. It moves the staging work it can safely apply while keeping unrelated live-site work. WooCommerce stores receive additional protection for live orders, customers, stock, sessions, webhooks, scheduled actions, and payment settings.
Documentation:
https://emunot.com/stagebridge/
Core Features
- Smart Push - Push staging changes without losing unrelated work added to your live site.
- WooCommerce safety - Keep live orders, customers, stock, sessions, webhooks, scheduled actions, and payment settings protected during a Smart Push.
- 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.
- 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.
屏幕截图:
常见问题:
Does StageBridge push every production table and file by default?
No. Sync and push operations compare files and database tables so unchanged items can be skipped. Push is safe by default and tries to preserve production changes made since the last clone, sync, or push.
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.0
- Detects WooCommerce stores and HPOS order storage.
- Protects live orders, customers, stock, sessions, payment credentials, webhooks, and scheduled-action data during Safe 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.