Wp Rest Laravel Package

Technical Evaluation

• Architecture fit: pollora/wp-rest is a framework-agnostic WordPress REST controller/attribute-discovery package extracted from pollora/framework (src/WpRest) with history preserved. Its deliberate decoupling from the Laravel application container (controllers built by the discovery's instance resolver, HandlesAttributes receiving the PSR-11 container) means it can be adopted without adopting the full Pollora framework, but it also means it does not lean on Laravel's routing, middleware, or service container in the way a typical Laravel package would. Fit is best for teams running WordPress inside or alongside a Laravel/PSR-11 stack.
• Integration feasibility: High for a v0.1.0: class names unchanged (Pollora\WpRest\*, Pollora\Support\WpGlobals) preserve drop-in compatibility for existing Pollora users, and WpGlobals suggests an explicit bridge for WordPress globals rather than hidden coupling. The PSR-11 constructor injection point is a clean seam for our own container.
• Technical risk: Primary risk is version-cadence risk, not code risk: the maintainers explicitly state 1.0.0 ships with the framework's next major release, so v0.1.0 is a preview surface likely to move. Extracted-from-monorepo packages commonly carry residual assumptions (autoload maps, test scaffolding, undocumented WordPress bootstrap expectations). The architecture test constraining dependencies to attributes/discovery/PSR/WordPress is a genuine positive signal for long-term maintainability, but it also constrains future feature velocity.
• Key questions: Which Laravel and WordPress versions are in the supported matrix? Is the PSR-11 container required or optional for zero-dependency use? What is the discovery/caching story for controller registration on every request? Does WpGlobals cover multisite and CLI contexts? What is the 1.0.0 timeline relative to the framework release, and will v0.1.x receive fixes meanwhile? Is pollora/framework still shipping WpRest (duplicate-class risk)?

Integration Approach

• Stack fit: Suitable where we already run PHP 8.x with Composer and a PSR-11 container, and need attribute-driven WordPress REST route registration. Not a fit if the team expects Laravel-native routes/api.php ergonomics or Laravel middleware pipelines.
• Migration path: Two paths. (a) Greenfield: install standalone, register controllers via attributes, wire the container into WpRestDiscovery. (b) Existing Pollora consumers: swap to the standalone package once pollora/framework drops or aliases src/WpRest; confirm no duplicate class definitions during the overlap, and pin one source of truth. For either path, keep Pollora\Support\WpGlobals usage isolated behind a thin internal adapter so a future 1.0.0 API shift is a one-file change.
• Compatibility: Class names are unchanged, which lowers migration cost but creates namespace-collision risk during side-by-side installs. Verify the package's composer.json conflict/provide rules against pollora/framework before adding it to an existing app. Confirm WordPress minimum version and whether the discovery relies on REST API internals that shifted across WP releases.
• Sequencing: 1) Spike in a non-production branch: register one controller, resolve one constructor dependency, one custom HandlesAttributes attribute. 2) Add a contract test asserting route registration and container resolution against our pinned WP/Laravel versions. 3) Land on one low-traffic endpoint behind a feature flag. 4) Broaden only after the 1.0.0 release lands, or after we accept the cost of a breaking-change upgrade from 0.1.x.

Operational Impact

• Maintenance: Low surface area by design (attributes + discovery + PSR contracts + WordPress), which is favorable for a small team. Offset by pre-1.0 status: expect at least one breaking change, so budget a scheduled upgrade rather than incidental updates. Keep our attribute usage behind our own wrapper classes to shrink the blast radius.
• Support: Small-maintainer package extracted from a framework; support channel is likely the upstream repo only. We should assume self-support and own the fallback: ability to vendor or fork, which the preserved history and unchanged class names make viable. Record that fork option explicitly as our continuity plan.
• Scaling: Discovery-based registration runs per request; cost depends on whether discovery results are cached and how many controllers/attributes exist. For high-traffic sites, measure discovery overhead early and confirm an opcode/object-cache story. No database or queue components are introduced, so scaling risk is contained to request-time CPU.
• Failure modes: Container misconfiguration yields constructor-resolution failures at discovery time (fail-fast, but potentially fatal rather than degraded); duplicate classes if pollora/framework still ships WpRest; WordPress global expectations unmet in CLI, cron, or multisite contexts via WpGlobals; silent route non-registration if discovery is mispointed. Add startup assertions plus an integration test that enumerates registered routes.
• Ramp-up: Moderate for Laravel developers, low for existing Pollora users. Attribute-based routing is idiomatic but unfamiliar to teams used to explicit route files; new adopters must also learn the discovery lifecycle and the PSR-11 injection contract. Estimate roughly a half-day spike for an experienced PHP developer, and document the discovery flow internally before wider rollout.