Testing with a Staging Site

Testing a plugin update or a new add-on on your live site is the fastest way to find out something is broken in the worst possible way — while real subscribers are trying to access their feeds. A staging site is a private copy of your WordPress installation where you can test changes before they affect anyone.

This guide covers what staging mode does, how to read the visual indicators, how to manage your staging subscriber set, and what your subscribers will actually experience during a test.

---

What a Staging Site Is

A staging site is a full copy of your production WordPress site — database, files, themes, and plugins — running at a separate URL. It is not visible to the public. Changes you make on staging have no effect on your live site until you deliberately apply them.

Most managed WordPress hosts include staging as a built-in feature:

If your host doesn’t offer built-in staging, plugins like WP Stagecoach or BlogVault can create staging environments. Local development tools like Local (by Flywheel) or DevKinsta work well if you’re comfortable developing on your own computer.

On most managed hosts, staging counts against the same plan limits as your live site. WP Engine and SiteGround both work this way, and they are not unusual. A staging site is a full copy of your production site, so it brings a second copy of your storage, and its visits are counted alongside your real ones.

This catches people out in two ways. A site already close to its storage allowance can fail to copy across at all. And a plan measured in monthly visits now has your own testing counted against a number you were treating as audience — a busy testing week can push a site over a threshold it has never come near before.

Check your host’s staging policy against your current usage before you create one, particularly if you are near a limit. Some hosts exclude staging traffic from visit counts, some don’t, and the storage almost always counts either way. If your plan is tight, a local development tool keeps the whole copy off your hosting account.

---

How Benecaster Behaves on Staging

When Benecaster detects it is running on a staging site, it changes its behavior automatically. You don’t need to configure anything.

The Orange Border

Every screen in wp-admin — not just Benecaster screens — shows a 4px orange border (#e87a00) framing the page whenever staging mode is active. It renders as a fixed overlay with pointer-events: none, so it never intercepts your clicks or interferes with normal admin use. It is always there and cannot be hidden.

It exists for one reason: to make it impossible to accidentally work on the wrong site. If you open a browser tab and don’t see the orange border, you’re on production. If you see it, you’re on staging, regardless of where in wp-admin you happen to be.

The Staging Banner

A non-dismissible banner appears at the top of every Benecaster admin screen. The copy adapts based on whether your plan caps the staging subscriber set:

• If your plan has a staging cap: “Staging mode active — limited to N staging-active subscribers”
• If your plan has uncapped staging access: “Staging mode active — feed access is uncapped”

The banner cannot be dismissed. On the right side of the banner you’ll find the Clear feed cache button, described below.

Feed Access Is Limited to the Staging Active Set

On staging, only subscribers you’ve explicitly added to the staging active set have working feeds. Everyone else’s token is treated as invalid for the duration of their visit to the staging URL — their production tokens are untouched, and they have no idea this is happening.

The other subscribers’ token rows in the database remain status = 'active'. Benecaster intercepts validation before the token check and returns an empty feed for any token whose owning user is not in the staging active set. This is why a subscriber you remove from the staging set sees an empty feed without their token being revoked.

On production, this validation branch is a no-op. Token validation works exactly as it always has.

The Feed Cache Refreshes Faster

On staging, the feed cache TTL is 45 seconds, compared to the normal production cache TTL. This means you can make a change — publish an episode, adjust tier availability — and see it reflected quickly without manually clearing the cache every time.

Developers: The staging cache TTL is controlled by the BENECASTER_STAGING_CACHE_TTL constant. Add it to wp-config.php on your staging site to override the 45-second default:

define( 'BENECASTER_STAGING_CACHE_TTL', 120 ); // 2 minutes, in seconds

No Upgrade Plan Button

On staging, Settings → Account → Plan changes shows no Upgrade plan button. In its place: “This is a staging copy of your site, so your plan can’t be upgraded from here.” with a link to your account page at benecaster.com. This isn’t just a UI restriction — the licence server itself refuses to upgrade a staging site’s plan, so the plugin doesn’t offer a button that would only fail.

---

How Benecaster Detects Staging

Staging status is not fixed when you connect — it is re-checked, and it can change afterwards. If your staging address was not recognised when you connected, it can start being recognised later without you reconnecting or touching anything; and a site that stops being staging starts counting against your limit again.

⚠ If your staging site is being counted against your limit, contact support. Recognition works from the address, so a staging site on an address carrying none of the usual markers is invisible to it. There is nothing to configure on your side — we add your host’s pattern, or mark that one site by hand, and it takes effect on your site’s next check-in.

Benecaster recognizes staging environments automatically from the site URL. It matches staging markers in the hostname, not a list of hosting companies — so a given host may appear here in some URL shapes and not others. If your staging URL carries one of these markers, staging mode activates without any configuration.

Some markers are built into the plugin and work fully offline:

• A staging label anywhere in the hostname, optionally numbered — staging.yoursite.com, staging1.yoursite.com (SiteGround numbers its staging subdomains this way), app.staging.yoursite.com, yoursite.staging.wpengine.com (WP Engine’s older staging address)
• yoursite.local — local development environments
• localhost — local development
• yoursite.test — local development
• A private or reserved IP address — 192.168.x.x, 10.x.x.x, 127.0.0.1, ::1

Others come from a small list we publish and Benecaster checks once a day, rather than being bundled with the plugin itself — currently Flywheel staging URLs (*.flywheelstaging.com) and ngrok tunnel URLs (*.ngrok.io, *.ngrok.app). Your site caches the list it fetched (it never expires, and a failed daily check just keeps yesterday’s list rather than losing recognition), so this works even if your site can’t reach us at the exact moment it checks in. The practical difference from the first group: because this list lives on our server rather than in the plugin, we can recognize a newly-added hosting vendor’s staging address on your site without you having to update Benecaster first.

The staging label has to be a whole piece of the hostname, between dots. staging-yoursite.com and stagingsite.yoursite.com are not detected — those are somebody’s production address, and the reason for the caution is below.

What Benecaster Deliberately Does Not Detect

Some URL shapes look like staging but aren’t reliably staging, and Benecaster leaves them alone on purpose. If your host is in this list, that isn’t an oversight — use the BENECASTER_STAGING constant below.

• *.wpengine.com — this is the temporary address a WP Engine Production environment serves from until you point a custom domain at it, so matching it would switch brand-new live sites into staging mode on their first day. Your WP Engine staging site is still detected if it uses the older yoursite.staging.wpengine.com shape, because of the staging label — nothing has changed for that address.
• *.wpenginepowered.com — WP Engine gives Production, Staging and Development the same {environment}.wpenginepowered.com address, and you choose the environment name yourself. There is nothing in the URL that says which is which.
• *.kinsta.cloud — Kinsta’s documented temporary URL for a live site, not for its staging environment. Same problem as *.wpengine.com, for the same reason.
• *.kinsta.com — Kinsta’s legacy production temporary URL. Matching it would switch real production sites into staging mode.
• *.dev — a genuine public domain ending since 2019, used by ordinary production sites. Its old role as a local-development convention ended then; .test and localhost replaced it and are both detected.
• dev.yoursite.com — most often a production developer portal or docs site rather than a development copy.
• A public IP address — genuinely ambiguous, since a small production site can run on a bare public address. Private and reserved addresses are detected; public ones are not.
• Pantheon and Cloudways staging URLs, for the same reason as WP Engine’s newer URLs — nothing in the address distinguishes the environments.

Why the list errs toward not detecting. The two mistakes are not equal. If Benecaster wrongly decides your production site is staging, that site stops being able to save live Stripe keys, and its subscribers stop counting toward your plan’s limits — so the warnings that would normally tell you that you are outgrowing your plan never arrive. You can at least tell the state at a glance: a site in staging mode wears an orange border across the top of every admin screen. If Benecaster misses your staging site, the cost is smaller and quieter: live Stripe keys become saveable on a copy of your site where they should not be, and your staging subscriber set is not used. When a URL is ambiguous, Benecaster treats it as production — the mistake that at least announces itself.

Turning Staging Mode On Yourself

If your staging site uses a domain that doesn’t carry any of these markers — a password-protected subdomain you manage yourself, or one of the hosts above — add one line to that site’s wp-config.php:

define( 'BENECASTER_STAGING', true );

Add this above the /* That's all, stop editing! */ line. Staging mode will activate on the next page load.

To turn it off again you can either remove the line or set it to false — define( 'BENECASTER_STAGING', false ); genuinely turns staging mode off, rather than switching it on by the mere fact of being written. The same is true of BENECASTER_IS_PRODUCTION below.

If you also have BENECASTER_IS_PRODUCTION set, this line does nothing. See The Escape Hatch — the production declaration wins over everything, including this constant and including hostname detection.

---

Working with the Staging Subscriber Set

The staging subscriber set is managed from Benecaster → Subscribers. Staging controls are only visible when staging mode is active — on a production site, this screen looks and behaves normally.

Reading Subscriber Status

Each subscriber row shows a staging status indicator:

• Orange dot — this subscriber is in the staging active set. Their feed works on the staging site.
• Grey dot — this subscriber is not in the staging set. They’ll see an empty feed on the staging site.

Per-Row Actions: Activate and Deactivate

Each subscriber row includes action links for staging management:

• Activate in staging — adds this subscriber to the staging active set. If your plan has a cap and the set is already full, this opens the swap modal instead (see below).
• Deactivate from staging — removes this subscriber from the staging active set. Their token remains valid; they simply won’t get a working feed on the staging site.

Swapping When at Cap

If your plan caps the staging active set and the set is full, clicking Activate in staging on a new subscriber opens the swap modal. The modal lists your currently staging-active subscribers along with their tier badges, so you can pick who to swap out. The selected subscriber is deactivated and the new one takes their place. Changes take effect immediately — no cache clear needed.

Resetting the Staging Set

The Reset staging set button in the subscriber list toolbar rebuilds the staging set from scratch. It replaces the entire existing set and fills it to the cap with at least two subscribers per tier, choosing by join date oldest first. Use this when you want a representative baseline without manually picking subscribers one by one.

The Orange Gap Notice

If any of your configured tiers has zero subscribers in the staging active set, an orange notice appears above the subscriber table identifying which tier has no coverage. Clicking the tier name in the notice filters the subscriber list to that tier so you can activate someone quickly.

Developers: The subscriber set is managed by four REST endpoints under benecaster/v1/staging/set/ — GET /set, POST /set/add, POST /set/remove, and POST /set/reset. When POST /set/add is called while the set is at capacity, it returns 409 benecaster_staging_at_cap; the admin UI responds to this by opening the swap modal. All four endpoints require manage_options capability and a valid X-WP-Nonce header. See the Staging REST API reference for full request and response documentation.

---

Clearing the Feed Cache

The staging banner includes a Clear feed cache button on the right side. It is always visible when staging mode is active. Use it after making episode changes to force feeds to regenerate immediately, rather than waiting out the 45-second TTL.

The button has three visible states:

There is no confirmation dialog.

Recommended workflow: Edit an episode → click Clear feed cache → reload a staging-active subscriber’s feed URL in your podcast app to verify the change.

---

Testing a New Membership Tier on Staging

If you’re testing how a new membership level works, follow this sequence:

1. Create the membership level
Add the new level in your membership plugin (MemberPress, RCP, etc.) as you normally would.

2. Map it to a Benecaster tier
Go to Benecaster → Settings → Subscription → Tier Mapping and map the new level to a Benecaster tier. Benecaster will show a notice if no staging-active subscribers exist for that tier.

3. Create a test subscriber
Use your membership plugin’s admin tools to create a test subscriber. A token is generated and a welcome email is sent. But the feed won’t work yet — the subscriber isn’t in the staging active set.

Going through the actual purchase flow with a Stripe test card only works on a staging site that was installed separately, not one cloned from production. On a clone, Benecaster refuses every billing operation regardless of key mode, so the purchase fails with “Billing changes are temporarily unavailable on this site.” — test card or not. See First: How Was Your Staging Site Made? The admin-tools route above works on either kind, which is why it is the recommended one here.

4. Activate the test subscriber in staging
Go to Benecaster → Subscribers, find the subscriber you just created, and click Activate in staging.

5. Test the feed
The subscriber’s feed URL should now return their tier’s episodes. Check that the right episodes appear, that availability dates are working, and that tier-restricted episodes are correctly absent.

---

Testing Payment Features on Staging

When you’re testing Benecaster’s built-in subscription system or a payment gateway add-on (PayPal, etc.), staging introduces a specific risk: your staging database is a copy of production, which means your live payment credentials may already be present.

Always use test credentials on staging. Running subscription flows with live credentials on a staging site can result in real charges to real subscribers.

🔴 First: How Was Your Staging Site Made?

This determines whether you can test payments at all, and it is the single most important thing on this page. Benecaster treats two kinds of staging site very differently:

Benecaster records the address it first ran at, and refuses to move money once it finds itself running somewhere else. A cloned site inherits production’s recorded address along with the rest of the database — so the mismatch gives it away immediately, and the protection arms itself without anyone configuring it.

This is not the same check as the live-key refusal below, and it does not care what mode your keys are in. Test keys do not lift it. The reason is that a clone carries your subscribers’ real Stripe subscription IDs, and those stay real whatever keys are loaded — a cron run or a replayed webhook could cancel or re-tier a genuine paying subscriber without a penny moving. Key mode cannot catch that; only knowing the site is a copy can.

On a cloned staging site, a billing action fails with “Billing changes are temporarily unavailable on this site.” Your explanation — naming both addresses — is in the debug log, once per operation per hour.

The fix is not BENECASTER_IS_PRODUCTION. See The Escape Hatch below: putting it on a copy disarms every protection on the one install they exist to watch. If you need to rehearse a real purchase flow, use a separately-installed staging site rather than a clone.

Benecaster Refuses Live Stripe Keys Off Production

When you paste live Stripe keys into an install that Benecaster does not believe is production, the save is refused — nothing is written, and the error tells you why and how to proceed. This applies both to the site-wide keyset at Settings → Membership → Payments and to a single show’s own keys at Shows → [show] → Settings → Payments.

Two independent signals can trigger the refusal, and they catch different mistakes:

• This install is a copy. Benecaster records the URL it first ran at and compares it to the URL it is running at now. A staging copy inherits the recorded production URL from the database it was cloned from, so the mismatch gives it away — even at an ordinary domain that looks nothing like staging. The message names both URLs.
• This install looks like a staging environment. The same markers listed under How Benecaster Detects Staging — a staging label anywhere in the hostname, localhost, *.local, *.test, a private IP address, Flywheel, ngrok — or the BENECASTER_STAGING constant. This catches a site that has always lived at a staging hostname, which the copy check cannot see.

Test keys are never refused, on any install — putting test keys on staging is exactly what this is steering you toward. Clearing a keyset is also always allowed, so you can always get out of a live configuration.

The Escape Hatch: BENECASTER_IS_PRODUCTION

Sometimes a real production site trips a detector. The realistic cases are a production site genuinely served from an address that carries a staging label, and a production site that has legitimately changed domain since Benecaster first recorded it — the second is the more common of the two.

There is exactly one route back. Add this line to your wp-config.php, above the “That’s all, stop editing” comment:

define( 'BENECASTER_IS_PRODUCTION', true );

This declares the install production outright, and it wins over everything else: both live-key signals, the BENECASTER_STAGING constant, and hostname detection.

Staging mode itself switches off too, not just the key refusal. The orange border goes, the staging subscriber set stops applying, and the daily licence ping reports the site as production — so its subscribers count toward your plan limits again. That is the whole point of the declaration, but it is worth knowing before you add the line to a site you were treating as staging.

If both constants are set — which happens when a wp-config.php is copied between environments and only half of it is edited — the site is production. That is the safe way round. The alternative would let a forgotten BENECASTER_STAGING strip a genuine production site of its plan limits with no way to override it, and a declaration of production can only ever remove that install’s own safety rails — it buys nothing from Benecaster’s side, which works out a site’s environment from its verified hostname regardless.

It has to live in wp-config.php, and there is no setting in the admin that does the same thing. That is deliberate, for two reasons. A database-stored override would be wiped by the next staging refresh, so you would set it again after every pull. Worse, it would travel — restore a staging database over production, or clone in the other direction, and the override lands on the copy, disarming the guard on precisely the install it exists to protect. wp-config.php is not part of a database copy, so the declaration stays with the install that made it.

Do not add this to a staging site to get past the refusal. It removes the guard entirely on that install, and the next live keyset you paste is stored on a copy that can charge real cards.

Stripe Test Mode

Stripe provides a complete test environment with separate API keys. Test mode keys start with sk_test_ and pk_test_ — they look just like live keys but all transactions are simulated, no real money moves, and test customers/subscriptions never appear in your live Stripe dashboard.

To switch to test mode on your staging site:

1. Log in to your Stripe Dashboard
2. Toggle Test mode on (top-right switch)
3. Go to Developers → API keys and copy your test Publishable and Secret keys
4. In your staging WordPress site, go to Benecaster → Settings → Payments and replace the live keys with your test keys

On a multi-show site, that step is not the whole job. Any show with its own Stripe account holds its own keys and its own test/live mode, at Shows → [show] → Settings → Payments. Switching the site to test does not switch those shows — a show can be on its own live keys while the site sits in test. Check each show that has its own account.

When the site default is test mode, Benecaster shows a TEST MODE badge on all payment-related admin screens. The badge is not the check to rely on here. It reports whether any payment gateway is in test mode, which is a different question from whether any show is taking real money — a show on its own live keys raises no badge at all. The safety warning below is what catches that, and the payment mode banner names which shows are in which mode. See Test Mode.

Standard test cards:

Use any future expiry date and any 3-digit CVC.

PayPal Sandbox (PayPal Add-on)

PayPal provides a Sandbox environment at developer.paypal.com. Sandbox credentials are completely separate from your live PayPal credentials — there is no automatic detection. You must configure Sandbox credentials explicitly in your staging WordPress site.

1. Log in to the PayPal Developer Dashboard
2. Under Apps & Credentials, switch to Sandbox
3. Create or select a Sandbox app and copy the Client ID and Secret
4. In your staging site, configure the PayPal add-on with the Sandbox credentials and enable Sandbox mode in the add-on settings

Safety Warning: Live Keys on Staging

If Benecaster detects that anything on your staging site would charge a real card, it shows a persistent warning:

Live payment keys detected on a staging site. Subscription actions on this staging site may result in real charges. Switch to test credentials before testing payment flows.

The warning names what is at fault, because on a multi-show site “somewhere on this install” is not something you can act on. It adds a sentence for each source:

• “The site-wide Stripe account is using live keys.”
• “These shows are on their own live Stripe keys: …” — with the shows named.

Both can appear together. When exactly one show is at fault and the site account itself is clean, the warning’s button opens that show’s Payments tab rather than the site-wide settings screen — there is nothing to fix on the site panel in that case.

A show is named only when it is on its own live keyset. A show that uses the site’s Stripe account has no keys of its own to be wrong, so it is covered by the site-wide sentence instead. If the warning names no shows, the fix is at Settings → Membership → Payments; if it names shows, fix each one on its own Payments tab.

This is a check on credentials, not on the Test Mode toggle, so a cloned production site is caught even if nobody remembered to switch anything. It appears above the regular staging banner and cannot be dismissed until no live credentials remain. If you see it, do not test any subscription flows until it clears.

This warning still matters even though live keys are now refused on staging. The refusal happens at the moment someone saves keys. A staging copy did not save anything — it inherited the live keys wholesale from the production database it was cloned from, so no save ever happened for the guard to refuse. The refusal stops you adding live keys to staging; this warning is what finds the ones that arrived with the copy.

On a cloned site, the warning is no longer the last line of defence — but it is still the only one that tells you. Billing operations on a copy are now refused outright, on the automated paths as well as the interactive one, so an inherited keyset can no longer quietly bill anyone through a cron run or a replayed webhook. What the refusal does not do is come and find you: it writes to the debug log. This warning is what puts the inherited keys in front of you, and clearing them is still the right thing to do — a separately-installed staging site carrying live keys has no clone check protecting it at all.

ℹ️ Listener Support donation keys are deliberately not part of this check. The warning is scoped to subscription payments, where a mistake creates an ongoing real-money relationship rather than a single charge.

---

Email Catch-All

On staging, you probably don’t want test emails going to your real subscribers. An email catch-all redirects all outgoing email from your staging site to a single inbox — usually yours — so you can see exactly what subscribers would receive without actually sending to anyone.

Using Emails Catch All (free) — simplest option:
Install Emails Catch All on your staging site and set a catch-all address. Every email the site sends goes to that address instead of the real recipient — one setting, nothing else to configure. It can also send you a copy while still delivering normally, which is not what you want on staging: choose the mode that replaces the recipient.

A redirected email still looks like it came from your site. Subject, sender and content are unchanged — only the recipient differs. It is genuinely easy to read one in your own inbox and react to it as though a real subscriber had received it. Watch which site it came from before acting on anything.

Using WP Mail SMTP:
Install WP Mail SMTP on your staging site. In the plugin settings, you can enable Email Log to capture all outgoing emails in the WordPress dashboard without sending them at all.

Using Mailtrap:
Mailtrap.io (free tier available) is a test email inbox. Configure WP Mail SMTP to use Mailtrap’s SMTP credentials, and all outgoing email from your staging site lands in your Mailtrap inbox — never delivered, fully readable. You’ll see the full email including subject, headers, and rendered HTML exactly as a subscriber would receive it.

Either approach lets you verify that welcome emails, episode notifications, and token reset emails all contain the right content and working links before you ever test on production.

User Switching (Login As)

The User Switching plugin by John Blackbourn lets you instantly log in as any other WordPress user with a single click — no password needed.

On staging, this is invaluable. After making a change, you can log in as one of your staging-active subscribers and check:

• Does their feed URL still work?
• Does the subscriber account page show the right information?
• Can they access the episodes they should be able to access?

To use it: install and activate the plugin, then go to Users in the WordPress admin. Each user has a “Switch To” link. Click it to instantly become that user. Click “Switch back to [your name]” in the admin bar to return to your account.

This is significantly faster than opening a private browser window, logging in as a test subscriber, and checking manually.

---

Applying Changes to Production

Once you’ve tested your update or new add-on on staging and everything works:

1. Apply the update on your production site from Plugins → Available Updates (or Benecaster → Add-ons for add-ons)
2. Check that the orange border does not appear on your production admin — if it does, staging mode is active on the wrong site
3. Do a quick sanity check: confirm your feed is reachable, check that one subscriber can access their feed, check the dashboard for any unexpected notices

See Updating Benecaster Safely for the full production update checklist.

---

Why Benecaster Staging Works This Way

The Benecaster challenge: when your hosting provider creates a staging site, it copies your entire database. Your real subscriber records, tokens, and membership data are all there.

Most staging setups ask you to clean up this data manually — delete test entries, anonymize emails, and so on. That’s a hassle every time you refresh staging, and it’s easy to skip.

Benecaster takes a different approach. The data stays exactly as copied. Benecaster simply limits which subscriber feeds work on the staging domain to a subset you choose. Your real subscribers’ tokens exist in the database, but they only return empty feeds on staging — so if someone somehow accessed your staging URL, they’d see nothing.

This protects you from three things:

1. Accidentally emailing real subscribers from staging.
Because staging mode is visible (the orange border, the banner), you’re less likely to trigger an email blast thinking you’re on production.

2. Accidentally treating staging as a second production site.
If only 25 of your subscribers have working feeds on staging, the other hundreds would immediately notice their feeds are broken. A misconfigured staging site being used as a real site becomes obvious and self-correcting.

3. Staging activations inflating your plan metrics.
Subscriber counts from your staging site don’t count toward your plan limits. A staging site with 500 subscriber records copied from production reports as 25 subscribers (or fewer) to the license server — it won’t trigger a tier upgrade or affect your billing.

For Pro, Multi-Show, and Studio plans — which all have unlimited production subscribers — there’s no subscriber count ceiling to protect, so the 25-subscriber cap doesn’t apply. All your subscribers have working feeds on staging on those plans.