Skip to content
Corex

AccessRequestFormController

Corex\Config\Access\AccessRequestFormController · class · Config layer

Where the “Request access” button posts (spec 079, FR-001). Before this existed the denied surface’s form posted the browser straight at rest_url('corex/v1/access/requests'). Nothing was broken: the controller returned JSON because it is a REST endpoint, and the browser rendered what it was given. The request even succeeded — so the person asking for help was shown an operation envelope and had no way to tell that anyone would ever see it. This handler is the browser’s half of that endpoint. It calls the same {@see AccessService} method the REST route calls, so the two cannot drift, then redirects (POST/redirect/GET) back to the screen the person was refused from. The REST route is untouched and still answers JSON. The redirect carries no arguments at all. Success is read back out of the database by the denied surface, which means a refresh, a bookmark and a visit tomorrow all show the same true state, and no confirmation can be conjured by editing the URL.

__construct(AdminGuard $guard, AccessService $service, AccessRequestFlash $flash)

Section titled “__construct(AdminGuard $guard, AccessService $service, AccessRequestFlash $flash)”

No register(). The provider hooks admin_post_{ACTION} to a closure that resolves this class only when the action fires — see the note there. Handing out a register() would invite make(...)->register() at boot, which is the thing being avoided.

Everything the submission decides, with nothing that ends the request. Split from {@see handle()} because exit cannot be caught: a test driving the whole handler takes the test runner down with it, so the decisions would go unproven and the only honest coverage would be a browser. Here each decision is an ordinary return value, and handle() is two WordPress calls that Playwright exercises for real.