Troubleshooting Account Flows
Diagnose state, route, permission and email problems in the right environment.
Troubleshoot account flows
Start by identifying the environment: local mock preview, installed WordPress theme, or a separate frontend. The same visible form can call different session systems in each environment.
Symptom Check first Next step Login/register form is blank Provider placement Place the component below WpAuthProvider Hook has no user property Hook choice Read the account through useWpUser() Preview cannot find an account Mock users and identifier policy Use an existing username/email; local passwords are simulated Signup succeeds but user remains null Verification/auto-login policy Show notice and offer verification or normal login Metadata is rejected registrationMetaFields and value types Approve only intended scalar profile keys in source Capability gate shows fallback Capability array and exact key Use a capability, not a role name; check the account's actual permissions Protected page redirects repeatedly Public login route and Page assignment Keep the login Page public and verify the installed destination Verification link is rejected Account ID, token and previous use Use a fresh link or normal login for a verified account Verification mail fails after signup Registration notice Retry sending verification; do not create the same account again Password link opens a missing page Frontend reset route Provide the destination and read login/key parameters Preview reset cannot complete Same browser and token store Request another preview link; do not use a WordPress key in the mock store API request misses a subdirectory Explicit base versus generated home path Inspect the request URL before changing credentials A JWT user appears but API denies access Backend token validation Check expiry, issuer/plugin and server permission checks |
|---|
Read current state in the rendered interface
After an action returns, a captured error variable may still belong to the previous render. Render error and notice from the hook and use the returned boolean for the action outcome.
Keep the browser network response and the visible error together when diagnosing a problem. Share error codes and routes rather than passwords, reset keys, verification tokens or session cookies.
Preview records and persistence
The development runtime loads mock users/roles, and signup/recovery workflows send record/log requests to the development API. Browser local storage holds mock sessions and tokens. Those writes do not create real WordPress users or send real mail. Development log requests are best-effort; inspect the development server if a log does not appear.
Recovery mock tokens have no WordPress expiry and resetting one does not replace a WordPress password hash. Verification resend currently leaves older unused server tokens valid until their own expiry/use. The deployment/security review remains responsible for origin, nonce, cache, rate-limit and account-disclosure policy; the guides do not promise protections that these hooks have not implemented.