Gorilla Staging Guard

FAQ

Where is the plugin’s screen?

Tools > Staging Guard.

Where is the documentation?

At https://docs.gorillaplugins.com/staging-guard/, also linked from the About tab under Tools > Staging Guard.

Do I need to set anything up?

No. Install it on the live site; every staging site made from then on protects itself. If the plugin cannot tell whether a site is the live one, it asks once on the Plugins screen.

How do I test email or checkout on a staging site?

On the staging site, under Tools > Staging Guard > Settings, list the addresses that may still receive mail, or switch on “Send to me”. Checkout works in each gateway’s test mode. Each choice applies only at the staging site’s address: a staging site freshly copied from the live site starts with all of them off again.

Can I set it in wp-config.php?

Yes. define( ‘GORILLA_STAGING_GUARD_MODE’, ‘production’ ); or define( ‘GORILLA_STAGING_GUARD_MODE’, ‘staging’ ); says what a site is, GORILLA_STAGING_GUARD_LIVE_URL names the live address, and define( ‘GORILLA_STAGING_GUARD_DISABLE’, true ); switches every protection off in an emergency. WP_ENVIRONMENT_TYPE is respected too. ‘copy’ and ‘clone’ are accepted in place of ‘staging’, and GORILLA_STAGING_GUARD_MODE also takes the environment’s name (‘development’, ‘test’, ‘local’, ‘acceptance’ or ‘sandbox’), which the admin bar then shows; unlike WP_ENVIRONMENT_TYPE set to ‘development’, it does not turn on WordPress’s debug mode.

I moved my site to a new domain. What happens?

It depends on the new address. A move to a new domain is asked about once, and the site keeps sending email and taking payments until you answer. A move to a subdomain of the old address (shop.example.com from example.com) or to an address named like a staging site (staging., dev., test.) is treated as a staging site straight away: choose “No, this is the live site” under Tools > Staging Guard, or add define( ‘GORILLA_STAGING_GUARD_MODE’, ‘production’ ); to wp-config.php before the move.

Can I check it from the command line?

Yes, with WP-CLI. “wp staging-guard status” says whether the site is treated as a staging site and why. “wp staging-guard test” runs the self-test (on the live site, as a staging site made from it would) and ends with exit code 1 when a protection is not working, so a deploy script can stop; add –expect-staging on a staging site to also stop when the site is not treated as one.

Does it work on multisite?

Yes. Each site in a network has its own status, recorded live address and activity, unless GORILLA_STAGING_GUARD_LIVE_URL is set in wp-config.php, which applies to every site. Sites in a network are not treated as staging sites of each other.

Does it work with other staging or email plugins?

Yes. It runs alongside SMTP and email log plugins, host staging tools, Staging Superpowers, Staging Shield, Disable Emails and Gorilla Essentials, and changes no setting in them. With Gorilla Essentials, the admin bar shows the environment once: Essentials’ label is hidden when both name the same environment, or on a staging site.

What does it change on a staging site?

Only what it reads, never what is stored. On a staging site:

• wp_mail() is stopped and reports success; WordPress’s mailer is readdressed to an address that cannot receive mail; BuddyPress and Events Manager are told to send through wp_mail(); MailPoet’s sending is held, so its newsletters stay unsent and still scheduled, and its SMTP server is pointed nowhere; WP Mail SMTP does not queue; requests to known email services are refused.
• Stripe, PayPal Standard, PayPal Payments, Mollie, Square, Authorize.Net and POLi read their settings as test mode. Saving a gateway’s settings on the staging site keeps its stored mode, so a staging site pushed back over the live site leaves the live site taking real payments.
• WooCommerce Subscriptions is told the site is a staging site, so renewals are not charged automatically. WooCommerce webhooks are not delivered.
• WP-Cron runs no tasks and Action Scheduler runs no actions; “wp cron event run –due-now” and “wp action-scheduler run” are refused.
• Requests to the live site are refused.
• Search engines are asked to stay away: “Discourage search engines” reads as on, its pages say noindex in their robots tag and their headers, and neither robots.txt nor WordPress offers a sitemap. A staging site kept private by another plugin stays private. The live site’s setting is never changed.
• A label in the admin bar shows logged-in people which site they are on: on a staging site, always, its environment (“Env: Staging”, “Env: Development”, “Env: Test”, “Env: Local”, “Env: Acceptance”, “Env: Sandbox”) from wp-config.php, the hosting, Gorilla Essentials, the word in its address (stg., dev., test., backup.) or its subdomain of the live site’s domain (“Env: Shop”), or Staging when nothing names it, and “[STAGING]” in front of the browser tab’s title; “Env: Production” on the live site, which you can switch off on the Settings tab.

Settings saved in other plugins are never changed. On the live site nothing is stopped; it only shows “Env: Production” in the admin bar, which you can switch off.

My live site’s renewals stopped. Can it tell me?

Yes. WooCommerce Subscriptions stops automatic renewals when it thinks a site is a staging site, usually after a change of address. On a site it knows is live, the plugin says so on the Plugins screen.

Settings > Reading on my staging site says search engines are discouraged. Did it change my setting?

No. On a staging site a public site’s setting is read as on without being saved, and saving that screen never stores it, so the live site stays visible to search engines after a push. Other choices you make there on the staging site, such as making it private with another plugin, are saved as usual. If a staging site becomes the live site at the same address (a new server tested before the switch), purge its page cache afterwards, so no page cached while it was a staging site keeps telling search engines to stay away.

What can it not stop?

Payment gateways it does not know (the list above is complete), mailers that talk to their email service on their own connection, a plugin that replaces wp_mail() and never hands the message to WordPress, files the web server sends without WordPress, anything run outside WordPress, such as a server cron job calling another script, and connections to the live site that bypass WordPress or go to another of its domains (name those with the gorilla_staging_guard_live_hosts filter). The Status tab names what it finds.

Can it stop every email?

No plugin can. Mailers that talk to their email service on their own connection, such as Mailchimp for WooCommerce, or a plugin that replaces wp_mail() and never hands the message to WordPress’s mailer, can still send. The plugin names those it finds. FluentSMTP (2.1.0 and later) replaces wp_mail() too, but asks WordPress first, so its email is stopped like any other.

Can search engines still find a staging site?

They can reach it, but are asked not to index it. robots.txt stays open on purpose: a search engine has to fetch a page to read its noindex, and a staging site that was already indexed would otherwise stay in the results. Files the web server sends without WordPress (uploaded PDFs, a robots.txt file saved in the site’s folder) and WordPress’s REST API do not carry the noindex header, and an SEO plugin’s own sitemap may still be built. To keep a staging site fully private, put it behind a password at your host.

Does it contact any outside service?

No. The plugin makes no requests of its own and sends nothing anywhere. On a staging site it only refuses requests that other plugins make to email services and to the live site.

What does the activity log keep?

For each stopped email: the time, the first recipient with all but the first letter hidden (j•••@example.com), how many recipients there were, the first 80 characters of the subject, and which plugin sent it. For a refused request or webhook: only the host name. Never the message, its headers or attachments, a full email address or the path of a web address. Entries are kept for 90 days unless you choose 30, 60, 180 or 365 on the Settings tab, at most 10,000 of them, in a small table of the site’s own. Deleting the plugin removes it only when you choose that on the Settings tab. The Activity tab shows 50 a page; the arrow at the end of a row shows its details.

Why is the live address stored backwards?

The live site records its own address so that staging sites can recognise themselves. Migration tools rewrite every copy of the old address in the database, so an address stored as it is would be changed too and the staging site would forget where it came from. Stored backwards, with a short prefix (for example gsg1:moc.elpmaxe), the address is not matched and survives. It is not meant to hide anything: you can read it backwards.

How do I report a security issue?

Please do not post it in the support forum. Report it privately through the contact form at https://gorillaplugins.com/contact/.

What is removed when I delete the plugin?

Nothing, unless you switch on “Delete all data when the plugin is deleted” on the Settings tab: then its settings, the live site’s recorded address, the activity table and each person’s answers are removed. Off by default, so the plugin picks up where it left off if you install it again. On a network each site decides for itself.