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:

Host	How to create a staging site
WP Engine	Sites → your site → Add environment → Staging
Kinsta	Sites → your site → Environments → Add New Environment
Cloudways	Application Management → Staging Management → Create Staging
SiteGround	Site Tools → WordPress → Staging
Flywheel	Your site → Create Staging

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.

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.

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

How Benecaster Detects Staging

Benecaster recognizes staging environments automatically based on the site URL. If your staging domain matches any of these patterns, staging mode activates without any configuration:

staging.yoursite.com — common staging subdomain
yoursite.local — local development environments
localhost — local development
yoursite.test — local development
WP Engine URLs (*.wpengine.com, which covers both staging and production WP Engine subdomains)
Kinsta staging URLs (*.kinsta.cloud)
Flywheel staging URLs (*.flywheelstaging.com)
Ngrok tunnel URLs (*.ngrok.io, *.ngrok.app)

If your staging site uses a custom domain that doesn’t match these patterns — for example, a password-protected subdomain you manage yourself — you can force staging mode by adding one line to your staging 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. Remove the line when you no longer need staging mode on that domain.

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:

State	What it means
Idle (default label)	Ready — no action in progress
Clearing…	Cache purge is running
Cleared.	Done — feeds will regenerate on next request

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
You can use your membership plugin’s admin tools to create a test subscriber, or go through the actual purchase flow using a Stripe test card. Either way, 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.

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 (Phase 2+)

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.

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:

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

When test mode is active, Benecaster shows a TEST MODE badge on all payment-related admin screens. If you see this badge, test credentials are configured correctly.

Standard test cards:

Card number	Result
`4242 4242 4242 4242`	Payment succeeds
`4000 0000 0000 9995`	Payment declined
`4000 0000 0000 3220`	Requires 3D Secure authentication
`4000 0000 0000 0341`	Attaches successfully but later payment fails (tests dunning)

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.

Log in to the PayPal Developer Dashboard
Under Apps & Credentials, switch to Sandbox
Create or select a Sandbox app and copy the Client ID and Secret
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 your staging site has live payment credentials configured, it will show a persistent warning:

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

This warning appears above the regular staging banner and cannot be dismissed until you replace the live keys with test credentials. If you see this warning, do not test any subscription flows until you’ve switched to test mode.

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 WP Mail SMTP (free):
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. This is the simplest approach.

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.

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:

Apply the update on your production site from Plugins → Available Updates (or Benecaster → Add-ons for add-ons)
Check that the orange border does not appear on your production admin — if it does, staging mode is active on the wrong site
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 core 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.