Protected Pages & Redirects
Declare page-wide authentication and capability requirements in pageConfig.
Protect an entire page
Use pageConfig when an exported Page template should require login before its content is served. A component gate only wraps part of a page.
1import { definePageConfig } from "@forgewp/react/config"
2
3export const pageConfig = definePageConfig({
4 protected: true,
5 allowed: "edit_posts",
6 redirect: "/login",
7})
8
9export default function EditorialDashboard() {
10 return (
11 <main>
12 <h1>Editorial dashboard</h1>
13 <p>Your editing workspace.</p>
14 </main>
15 )
16}definePageConfig supplies type assistance. A plain exported pageConfig object is also supported. Keep protected: true with the access declaration; allowed alone is not the documented way to protect a Page.
Setting Purpose protectedEnables page-wide protection allowedOptional WordPress capability required in addition to login redirectDestination for signed-out visitors; defaults to /login |
|---|
The compiler's page-config plugin injects useWpPageProtect() for local navigation and emits a protection marker. Export generates WordPress checks before the Page template's content. A signed-in account without the required capability is redirected to the site root. When installed email verification is enabled and the account is explicitly unverified, the generated protected Page redirects to its verification page.
Login policy and page policy are separate
blockLoginUntilVerified controls password-login behavior. Protected Page verification checks apply when email verification is enabled. Test both the account policy and the destination Page.
Pick a real destination
Use a developer-controlled path such as /login, adjusted for the site's installation path. The existing scaffold also uses template:login-page to resolve the installed login Page; local preview derives its route from that template name. WpPageLink-generated page-link markers are also handled by the protection runtime/compiler. Use the normal page-link workflow rather than writing those internal markers yourself.
Your login page should be public. A protected login page redirecting back to itself creates a navigation loop. Exporting a template does not by itself select the URL: assign it to a real WordPress Page and verify its permalink.
When to call the hook directly
useWpPageProtect(config) is exported for components that need the local client redirect behavior. It accepts the same protected, allowed, and redirect fields through WpPageConfig. A direct hook call is not a substitute for the exported Page's pageConfig or endpoint authorization.
Check each account state
Visitor Expected installed Page behavior Signed out Redirect to the configured login destination Signed in with required capability Serve the Page after verification checks Signed in without required capability Redirect to site root Explicitly unverified while verification is enabled Redirect to verification page |
|---|
Verify on the installed theme with separate accounts. Keep protected responses out of shared public caches unless the deployment correctly separates account-specific content.