The Onboarding Sandbox

The sandbox holds a member who still needs setup inside the funnel. They can browse the funnel pages and nothing else: every other URL bounces them back to the funnel page, silently. They type an address, hit enter, and land back on setup.

What the member can reach

Three groups of URLs are open to a sandboxed member:

• The funnel page itself. The page you picked in the module settings, the one with the password form.
• Additional Funnel Pages. Every page you list in the module settings joins the allowlist: the agreement, the welcome video, the 2FA setup page. Each one is audited by the status checklist, and a failing extra page disarms the whole sandbox (more on that below).
• Endpoints the site needs to function. The login screen, admin-ajax, the REST API, and the passkey and TOTP endpoints are allowed by URL pattern, so logins, form submissions, and 2FA enrollment keep working inside the funnel.

Everything else is off limits, including the member dashboard, the course library, and the shop. The member is not punished for trying; the bounce is a redirect, not an error page, and it carries them back to setup.

When the sandbox is armed

The sandbox enforces only when two conditions hold:

1. The sandbox toggle is on in the module settings.
2. Every status check passes: the funnel page exists, is published, contains the password shortcode, and is not password-protected, and every additional page passes the same published-and-unprotected checks.

The checks run through a cached health report that is invalidated the moment any funnel page is saved, trashed, or unpublished, or the settings change. If you unpublish the funnel page at 2am, the sandbox disarms at 2am rather than locking members out of a funnel that no longer exists.

Admins are never sandboxed. A logged-in administrator can wander anywhere, which makes testing straightforward: to see the sandbox from the member's side, use a non-admin test account.

The failure mode, and the order that avoids it

The one way the sandbox hurts you is a member trapped in a broken funnel: a password form that does not submit, an extra page that errors. The arming rules protect against the configuration version of this (a failing checklist disarms the sandbox), but not against a broken form on a passing checklist.

So build first, sandbox second. Write the funnel page, add the extra pages, run a test member through every step with the sandbox off, then switch it on when the checklist is green.

Letting a member out early

Sometimes the funnel is wrong for one person: a support case, a comped account, a member who set a password out of band. Their Member Profile has a clear-onboarding control that releases them immediately, without requiring the gates to have run.

The release deletes only the master "needs onboarding" flag. Completed gates keep their completion flags, and the enrollment reason (webhook, registration, or manual) stays on the account for audit, so the record of who entered the funnel and why survives the early exit.

After the last gate

When the final gate completes, the module clears the master flag and the sandbox lifts on the member's next request. There is no cache to wait out; the completion path invalidates immediately. The member who just set their password is redirected onward by the password form's redirect_to, and from that request on they are an ordinary member with full access, signed in under the password they chose.