Acorn Laravel Package

Product Decisions This Supports

• Build vs. buy on the integration layer. Acorn is the plumbing that boots Laravel's container, config, routing, and view layer inside WordPress. Building that in-house is a multi-quarter platform project with ongoing maintenance; adopting it lets the team spend that budget on product surface instead.
• Stack consolidation / roadmap. It is the deciding artifact for "do we standardize our WordPress builds on the Roots stack (Sage + Bedrock + Acorn)?" If the answer is yes, everything downstream — theme architecture, deploy pipeline, block templating, CLI tooling — inherits that decision.
• Feature feasibility calls. Because it supports illuminate/routing, validation, queue, cache, events, session, database, pagination, console, and view, previously expensive WordPress features (custom application routes, form validation, background jobs, Blade-rendered blocks and components, wp acorn commands, route caching) become routine work items rather than research spikes.
• Templating standard. Blade for views and blocks is a concrete, defensible choice versus PHP template partials or Twig — it matters for hiring, code review norms, and component reuse across projects.
• Ecosystem bets. Livewire support (since v4) and the community package layer (WooCommerce, ACF integrations) are the levers for "app-like WordPress" products — portals, gated content, dashboards — without leaving the CMS.
• Service-layer boundaries. Mail, notifications, broadcasting, Redis, and translation are explicitly unsupported. That is a scoping decision: plan those as WordPress plugins or external services up front rather than discovering it mid-build.
• Hiring and velocity. A single PHP framework idiom across Laravel services and WordPress sites reduces context switching and lets Laravel-fluent engineers contribute to WP work on day one.

When to Consider This Package

Consider it when all or most of these hold:

• You are on, or committing to, the Roots stack (Sage/Bedrock), or starting a greenfield WordPress build where the theme and application layers are yours to define.
• Your runtime supports PHP 8.3+ and you can absorb Laravel major upgrades on a roughly annual cadence (v6.x tracks Laravel 13).
• The site needs application-grade behavior: custom routes, validation, queues, caching, Blade componentization, CLI/automation.
• Your team already knows Laravel, or is small enough that one stack is better than two.
• You can pin versions, run staging, and maintain a CI upgrade path for a dependency with a small core maintainer group.

Look elsewhere when:

• You are retrofitting an existing non-Roots theme with heavy plugin coupling; the migration cost will dwarf the benefit versus adding features inside standard WordPress patterns.
• You must support PHP < 8.3 or cannot follow Laravel majors.
• Requirements hinge on first-party mail, notifications, broadcasting, or Redis-backed queues — those components are out of scope and you would be fighting the boundary.
• The product is a mostly-static marketing site where vanilla WordPress plus a block theme is cheaper to own.
• You need a commercial SLA, vendor support contract, or procurement-friendly provenance. This is MIT, community-maintained, sponsorship-funded software — support comes from the Roots community.
• You need the full WordPress admin/plugin ecosystem to remain untouched; Acorn sits at the theme/application layer and does not abstract plugin behavior.
• You are tempted by the experimental WordPress request handler (third-party HTTP middleware over WP responses). That was shipped, rolled back behind a flag in v4.0.2, and has not been promoted — do not put it on a roadmap.

How to Pitch It (Stakeholders)

To executives: Acorn lets us use Laravel inside WordPress, so one team with one skill set can build both our CMS-driven sites and our application features. It is MIT-licensed with no per-seat or license cost, actively maintained (releases through v6.3, currently tracking Laravel 13), and backed by the Roots ecosystem with sponsors including WordPress.com and Kinsta. The payoff is delivery speed and hiring flexibility: Blade components, routing, validation, caching, and queues we would otherwise hand-roll or buy. The cost is a platform commitment, not a line item — plan it as a migration with an owner, not a composer require.

To engineering: Acorn boots Laravel's container and providers inside WordPress and gives you most illuminate/* components — routing, validation, queue, cache, events, session, database, console, view — plus Blade, wp acorn CLI commands, route caching, and Livewire. It runs on PHP 8.3+, so confirm the host matrix first. Boundaries to respect: no mail, notifications, broadcasting, Redis, or translation — design around them. Track the upgrade guide for each major; v6 was a hard break, and the v4.0.2 request-wrapper rollback plus recurring Blade view-resolution and superglobal fixes show the WordPress/Laravel seam is where regressions land. Pin the version, keep a staging environment on the target Laravel major, and treat the experimental WordPress request handler as off-limits for production.

Numbers caveat for the business case: public adoption signals understate usage here — Acorn is a dependency of the Roots theme layer rather than something most teams install directly, so low dependent counts in package indexes are a measurement artifact, not a demand signal. Anchor the case on your own sites and team velocity, not registry metrics.