[abdul-kaioum]

Why

APIRouter registers every REST route with permission_callback => '__return_true', so middleware is the only gate on privileged routes. WordPress.org plugin reviewers reject that pattern, and WordPress can't answer 401/403 before the callback runs.

What

• RouteBase::permission(callable) sets a permission callback for a whole group (Route::group(...)->permission(...)).
• RouteRegister::permission(callable) overrides it for a single route.
• APIRouter registers $route->getPermissionCallback(): the route's own, then the group's, then '__return_true'. Routes that don't opt in behave exactly as before.

Group inheritance fix

Permission inside groups exposed a pre-existing RouteBase bug that affected prefix and middleware too:

• Route::permission(...)->get(...) (or ->middleware(...)) declared inside a group was dropped: the route registered against the group instead of its own RouteBase.
• Nested groups ignored their parent, and closing one reset the current group to null, so later routes in the outer group became ungrouped. A throwing group callback leaked its group.

Each RouteBase now records the group it was declared in and resolves prefix, middleware, permission, noAuth and ignoreToken through that parent when read; group() restores the enclosing group in a finally. Behaviour change: nested prefixes join (admin/inner) instead of the inner one replacing the outer, and a prefix set on a route inside a group is no longer lost.

Tests

TransportRegistrationTest covers the public default, group propagation to every method, and per-route override. RouteDefinitionTest covers attributes on routes inside a group, nested inheritance with sibling restore, and a throwing group callback. composer test (268), php-cs-fixer and composer compat pass.

Needed by the PaymentForm plugin's WordPress.org submission; it will move from ^2.4 to the release that carries this.

🤖 Generated with Claude Code