Sage Laravel Package

Product Decisions This Supports

• Build vs. buy for the theme layer. Sage is a free, MIT-licensed scaffold rather than a dependency — it answers "do we build a modern WordPress theme in-house?" with a pre-baked, battle-tested starting point. The real cost is adoption/ownership (forking and merging upstream), not licensing, so the build-vs-buy math should be framed as engineering time to reach a clean theme baseline versus onboarding cost plus a recurring merge cadence, not as a line-item purchase.
• Front-end tooling standardisation. Choosing Sage is effectively a decision to standardise on Blade + Vite + Tailwind across WordPress projects. That's a roadmap-level decision with payoff in shared CI patterns, shared component conventions, and easier cross-team movement — it supports "one front-end workflow for our polyglot Laravel/WordPress estate."
• Hiring and team topology. A Laravel-fluent team becomes productive in days; a WordPress-native team needs one to two weeks of ramp. This informs whether to staff the theme work with existing Laravel engineers or budget onboarding time — a resourcing decision a PM often owns.
• Feature delivery velocity. Blade components and Vite HMR directly shorten the loop for UI-heavy work (marketing pages, CMS-driven templates, search/filter experiences). It supports prioritising front-end-heavy roadmap items where iteration speed matters.
• Greenfield vs. rewrite scoping. Sage is a starter theme — adopting it for an existing classic theme is a template-and-pipeline rewrite, not an incremental change. This is a scoping/roadmap input, not just a dev preference.
• Maintenance budget on the roadmap. Because the theme is forked, not installed, every upstream release (e.g., v11.2.1's search quotation-mark fix) is a merge exercise with conflict potential. This supports a standing "theme maintenance" line item and a named owner with a monthly upstream-review cadence.
• Risk triage for specific releases. Small patches like v11.2.1 map cleanly to a PM decision: merge opportunistically, verify no local overrides shadow the fix (search form/results templates), smoke-test quoted/apostrophe/empty queries, avoid treating it as an emergency unless there's a confirmed security/escaping implication to escalate.
• Scaling and reliability expectations. Sage itself is stateless and scales fine; the failure modes that reach a PM are operational (stale Blade cache after deploy, Vite manifest mismatch if the build step is skipped). These are release-checklist and CI-reliability decisions, not product-feature decisions.

When to Consider This Package

Consider adoption when:

• You are starting a new WordPress theme and want a modern, maintainable front end from day one.
• Your team is already fluent in Laravel conventions (Blade, Composer, service providers, Tailwind, Vite) and you want one front-end workflow across projects.
• The site is UI- and CMS-heavy (marketing pages, content-driven templates, bespoke search/filtering) where component reuse and fast asset builds deliver visible velocity.
• You accept fork ownership: someone is accountable for upstream merges, and a monthly review cadence is realistic.
• You can meet the stack floor — PHP 8.1+, modern WordPress (6.x), Composer, Node LTS, Acorn — and can add a reliable Vite build step to CI/CD.
• You can live with community support only (GitHub issues, Roots Discourse) and plan internal first-line support.

Look elsewhere when:

• You expect to composer require this into an existing Laravel application — Sage is a WordPress theme scaffold, not a Laravel library.
• You need vendor SLAs or commercial support for a customer-facing site without internal front-line capability.
• Your team is WordPress-native and unlikely to adopt Blade/Acorn/Vite — the ramp and ongoing fork maintenance may outweigh the benefits.
• You cannot commit to periodic major-version rebuilds (Sage 9→10→11 each changed build tooling and Acorn coupling substantially); painless minor upgrades should not be assumed.
• You are migrating an existing classic theme and cannot fund it as a template/pipeline rewrite.
• You need stability over churn and cannot afford an added build step as a hard runtime dependency (a stale or missing Vite manifest is a deploy failure).

How to Pitch It (Stakeholders)

For executives — the one-paragraph summary. Sage is a free, MIT-licensed WordPress starter theme that brings Laravel-style discipline to WordPress front-end development: Blade templating, a Vite asset pipeline, and Tailwind CSS, all maintained by the well-regarded Roots team (13k+ stars). It is the right choice when we're building a new theme with a Laravel-fluent team and want one modern workflow across our estate. The cost is not licence fees but ownership: the theme is forked into our repo, so upstream releases — like the minor v11.2.1 search-query patch — arrive as merges to manage, and major versions (9→10→11) have historically required scheduled rebuild work. Bottom line: adopt it as a greenfield scaffold with a named maintainer and a monthly upstream-review cadence, not as a transparent dependency.

For engineering leadership — the practical case.

• Velocity: Blade components and Vite HMR shorten the UI iteration loop; Tailwind gives consistent utility-first styling.
• Consistency: aligns WordPress work with our Laravel conventions — shared CI patterns, shared Blade/Tailwind config, easier cross-team movement.
• Operational shape: the theme is stateless and scales fine; the constraints are WordPress itself (DB, object cache, page caching), not Sage. The one added architectural cost is a build step in CI/CD that must be reliable.
• Failure modes to plan for: stale Blade view cache after deploy (clear on release), Vite manifest mismatch if the build is skipped, search regressions where searchform/search-results templates are overridden locally, Acorn/PHP version drift on host upgrades, and WordPress core updates invalidating theme hooks.
• Support posture: community-only (GitHub + Roots Discourse), no vendor SLA — plan internal first-line support.

For the release decision (v11.2.1). This is a narrow correctness fix (quotation marks in the search query field) with no breaking changes, deprecations, or configuration deltas. It does not change the adoption decision. Recommended handling: merge or cherry-pick into a branch, run the Vite build and diff compiled assets, smoke-test search with quoted phrases/apostrophes/empty queries, confirm no local template overrides shadow the patched file, and promote in the next routine release window — not as an emergency, unless the change is confirmed to have escaping/XSS implications.

For resourcing — what we're asking for.

• A named theme owner (the de facto maintainer of our fork) and a monthly upstream-review cadence.
• Onboarding budget: days for a Laravel developer, one to two weeks for a WordPress-native developer to get comfortable with Blade directives, Acorn service providers, and the Vite workflow.
• A scheduled, deliberate migration project for the eventual next major (Vite/Acorn coupling), rather than assuming it rides along with routine minor upgrades.