Skip to content

What it stops

On a staging site, Gorilla Staging Guard holds back everything that could reach your customers, your payment accounts or the live site. On the live site it stops nothing.

It changes only what other plugins read, never what is stored. Nothing it forces on a staging site is saved, so a staging site pushed back over the live site leaves the live site working as before. Settings saved in other plugins are never changed.

Email

WordPress's email (wp_mail()) is stopped before anything is sent, and the sender is told it went out, so contact forms, orders and password resets behave as they do on the live site. Each stopped email is listed on the Activity tab.

Mail that goes around wp_mail() is caught where it can be:

  • WordPress's mailer is readdressed to an address that cannot receive mail.
  • WP Mail SMTP does not queue mail for later.
  • 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.

You can still receive mail yourself: see Test email and checkout.

Email services

Plugins that send through an email service's web API are refused on a staging site. The services covered: SendGrid, Mailgun, Postmark, SparkPost, Mandrill, Mailjet, Brevo (Sendinblue), Resend, MailerSend, SMTP2GO, Elastic Email, ZeptoMail, SendPulse, SMTP.com, SocketLabs, Netcore, the Gmail API, Klaviyo, Mailchimp and MailPoet's sending service.

Payment gateways

These WooCommerce payment gateways run in their test mode on a staging site:

  • Stripe
  • PayPal Standard (built into WooCommerce)
  • PayPal Payments
  • Mollie
  • Square
  • Authorize.Net (card and eCheck)
  • POLi

The gateway's own setting is not changed: it reads as test mode while the site is a staging site. Saving the gateway's settings on the staging site keeps the live mode it had stored, so a staging site pushed over the live site still takes real payments there.

Other gateways are not covered. The self-test lists the gateways it holds in test mode on your site. A developer can add a gateway with the gorilla_staging_guard_gateways filter: see For developers.

Subscription renewals

WooCommerce Subscriptions is told that the site is a staging site, so it does not charge renewals automatically.

On a site the plugin knows is live, it tells you on the Plugins screen if WooCommerce Subscriptions has stopped automatic renewals by itself, which usually happens after a change of address.

WooCommerce webhooks

WooCommerce webhooks are not delivered from a staging site, so your accounting, shipping or CRM tools do not receive test orders as real ones.

Scheduled tasks (WP-Cron)

WP-Cron runs no tasks on a staging site: no scheduled posts, no newsletter sends, no plugin jobs. wp cron event run --due-now is refused too.

Scheduled actions (Action Scheduler)

Action Scheduler, used by WooCommerce and many other plugins, runs no actions on a staging site. wp action-scheduler run is refused.

To test a scheduled job, switch on Let this staging site run scheduled tasks on the staging site. Payments stay in test mode whatever you choose.

Requests to the live site

A staging site cannot contact the live site through WordPress's own connections, so a test cannot change orders, stock or accounts there. Each refused request is listed on the Activity tab, with the host name only.

If your live site also answers at another domain, a developer can name it with the gorilla_staging_guard_live_hosts filter.

Search engines are asked not to list a staging site:

  • "Discourage search engines from indexing this site" reads as on.
  • Every page says noindex in its robots meta tag and its headers.
  • Neither robots.txt nor WordPress offers a sitemap.

robots.txt stays open on purpose: a search engine has to fetch a page to read its noindex, so a staging site that was already listed drops out of the results. The live site's setting is never changed.

A staging site kept private by another plugin stays private. To keep a staging site completely private, put it behind a password at your host.

The label in the admin bar

Logged-in people see which site they are on:

  • On a staging site, always: its environment, such as "Env: Staging", "Env: Development", "Env: Test", "Env: Local", "Env: Acceptance" or "Env: Sandbox", and [STAGING] in front of the browser tab's title. A staging site on a subdomain of the live site's domain shows that subdomain, such as "Env: Shop".
  • On the live site: "Env: Production", which you can switch off.

The admin bar with the label Env: Staging on the right

The label on a staging site.

What no plugin can stop

  • Payment gateways it does not know. The list above is complete.
  • Mailers with their own connection, such as Mailchimp for WooCommerce, or a plugin that replaces wp_mail() and never hands the message to WordPress. The plugin names those it finds on the Status tab. FluentSMTP 2.1.0 and later is stopped like any other: see Compatibility.
  • Files the web server sends without WordPress, such as uploaded PDFs, and WordPress's REST API: they do not carry the noindex header. An SEO plugin's own sitemap may still be built.
  • Anything run outside WordPress, such as a server cron job that calls another script.
  • 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).

Next step

The Status tab: see each protection working on your own site.