外掛標籤
開發者團隊
原文外掛簡介
A copy of a live website contains real customers, real orders and real service credentials. One cron run can send reminder emails to customers, renew subscriptions or call a payment service, silently and without warning. Staging Guard stops that on the copy.
Outgoing calls are blocked. Every call that goes through the WordPress HTTP API is refused immediately, except your own address, hosts on your allow list and, by default, WordPress.org (so updates and plugin installation keep working). The log shows which hosts were called and lets you allow one with a click.
Emails are caught, not sent. By default nothing leaves the site: each email lands in the Mail catcher tab with its recipients, headers and a safe preview. Alternatively redirect everything to one address, discard it, or let it through.
Scheduled tasks are paused. Due WP-Cron events are kept and run once you switch the protection off.
Search engines stay away. noindex, an X-Robots-Tag header and a robots.txt that disallows everything. Your Discourage search engines setting is never changed.
Visitors can be locked out (optional). Switch it on and everybody except administrators sees a short notice (HTTP 403, noindex) instead of the copy. Let in single IP addresses or ranges (IPv4 and IPv6), or share a secret access link that sets a 7-day cookie, for example for a client who reviews the copy. The page cache is kept out, REST requests and feeds are locked as well. It is off by default.
You always know where you are. A red marker in the admin bar shows on every page that the protection is on, and the Status tab says why.
A different address only shows a notice. If a copy still has the live settings but runs under another address, the plugin tells you and offers to switch the protection on. It never switches it on by itself, so a domain move of your live site can never silently block its emails.
Emergency switch. define( 'WP360_SG_DISABLE', true ); in wp-config.php switches everything off at once.
WP-CLI: wp 360-staging status|on|off|auto|hosts|allow
What this protects, and what it does not
Staging Guard is a safeguard against accidents, not an isolation.
It stops what goes through the WordPress HTTP API and wp_mail(). Code that calls curl, file_get_contents() or its own library directly (many payment and cloud SDKs) is not caught.
Plugins that talk to a mail service or SMTP directly, or replace wp_mail(), bypass the email protection.
The visitor lock covers pages, feeds, sitemaps and the REST API. The login page, the dashboard, scheduled tasks and AJAX requests stay reachable, so nobody gets locked out. Behind a proxy or CDN the IP list sees the proxy, use the access link there.
For real isolation, block outgoing traffic in the firewall or remove the service credentials from the copy.
Privacy
Caught emails can contain real customer data. They are stored in your database only, are visible only to administrators (on a multisite network only to super admins), are limited in number and age (50 emails, 7 days by default), never include attachments (only their names) and are removed when you delete the plugin. The log stores host names and counters only, never paths, parameters or content. The plugin itself makes no requests to other servers.
Free vs. Pro
The free version covers everything above.
Staging Guard Pro adds:
Service presets for common payment, newsletter, CRM, shipping, backup and AI services, each set to allow or block.
Single scheduled tasks can keep running while the rest stays paused.
Rules per path and method for allowed hosts (for example only GET on /v1/read).
Longer log and mail catcher (up to 500 entries), search, CSV export of the log, .eml export of an email and send as a test to one address.
Export and import of the settings for agencies that set up several websites the same way.
Automatic update notifications directly in the WordPress admin area.
