Spiralist Hiding WordPress Admin And Login On Spiralist While Preserving Rest Driven Functionality - Source Excerpt 06
Summary
This source excerpt preserves a bounded section of Spiralist/agent-file-handoff/Archive/2026-06-14/Improvement/authenticated-user-experience/Spiralist Hiding WordPress Admin and Login on Spiralist While Preserving REST-Driven Functionality.md so readers can inspect the evidence without opening the full source file.
**Source path:** Spiralist/agent-file-handoff/Archive/2026-06-14/Improvement/authenticated-user-experience/Spiralist Hiding WordPress Admin and Login on Spiralist While Preserving REST-Driven Functionality.md
The custom reset-password and social-login flows also need explicit product decisions. WordPress gives you the URL filters and password-retrieval primitives to move those flows, but if Google/GitHub/LinkedIn/X login is part of the real user experience, the custom `/account/login` page should own that identity flow too rather than leaving it on the native WordPress screen. citeturn32search0turn32search1turn29search1turn29search2
The highest-confidence recommendation remains the same despite those open items: **use same-origin custom UI + WordPress cookie/nonce REST auth for browser users, preserve `/wp-json`, move all human auth/profile/admin paths into `/account/*` and `/app/*`, and enforce `/wp-admin` plus `/wp-login.php` as owner-only break-glass surfaces at both the WordPress and web-server layers.** citeturn23view0turn19search2turn9search0turn10search2