Statamic Email Templates Laravel Package

Product Decisions This Supports

• Branded-email surface is now a real product surface, not just a CP concern. v2.9.1 makes EmailTemplates::resolve() accept branded => false in the array a caller's fallback returns, handing the body back untouched. The same brand-context that drives Control Panel chrome also frames outgoing email, so any decision about brand shell, logo, and header/footer now has a second, customer-facing blast radius. Product owners should track both surfaces when scoping branding work.
• A concrete, user-visible defect class: mobile rendering of self-contained templates. Marketing's template files carry their own header and footer; with a branded layout configured they were framed a second time, and on a phone the mail rendered wider than the screen. For a PM this is not cosmetic — it is a deliverability/perception issue in a channel customers actually see, and it argues for making "render at 320–400px" part of the template acceptance checklist rather than a post-launch QA catch.
• Template taxonomy decision: shell-dependent vs. self-contained. The fix only matters if you can answer "which of our templates bring their own header/footer?" The right move is an explicit inventory — transactional templates that want the branded shell, marketing/imported templates that must opt out with branded => false. Without that inventory the fix is available but unapplied.
• Opt-in by design, so no forced migration — and no automatic fix either. Without the key nothing changes, so there is no config migration, no regression risk, and no reason to hold a release window. The flip side: nothing is fixed until someone annotates the call sites. Track this as a small engineering chore attached to whichever team owns the marketing template pipeline.
• Upgrade sequencing across the package suite. The v2.9.0 navigation work still needs statamic-brand-context 1.16+ to be visible; this fix needs no version gate beyond the release itself. Two independent adoption conditions in one release series means the "did the upgrade actually do anything?" check has to be per-feature, not per-version.
• Build vs. buy for internal rendering plumbing. Both v2.9.0 and v2.9.1 reinforce the same argument: CP nav declaration and branded-email resolution are the kind of plumbing internal addon teams should not hand-roll. Following the convention keeps internal tools consistent with vendor addons and inherits fixes like this one for free.
• Docs, screenshots, and enablement timing. Any change to where settings live (v2.9.0) invalidates screenshots and macros; any change to email framing (v2.9.1) invalidates template previews. Schedule refresh against the actual brand-context version and the actual annotated call sites in production, otherwise docs and reality disagree.

When to Consider This Package

Adopt when:

• You run Statamic and your Control Panel is a real product surface for editors/admins, not just a dev convenience.
• You have two or more addons in the same install and care that Settings doesn't degrade into an undifferentiated list.
• You send branded email where some templates are self-contained (marketing, imported HTML) and others expect a shell — the branded => false escape hatch is exactly the seam you need, and hand-rolling it means re-implementing the same resolution logic.
• You already use, or are willing to adopt, statamic-brand-context 1.16+ — that's the version where the improved grouping actually renders.
• You want settings placement and email framing to be declarative and upgrade-safe rather than bespoke per addon.

Look elsewhere / deprioritize when:

• You're not on Statamic, or on Laravel alone — the Control Panel nav concepts here don't translate.
• You run a single addon with no suite ambitions and don't render email through this resolver; the grouping and template benefits are unobservable and you're paying dependency surface for nothing.
• Your email is templated in a third-party ESP (marketing platform, hosted builder) rather than in application-side HTML — this fix never runs.
• You're pinned to brand-context < 1.16 and can't move. The addon degrades gracefully, so it's harmless, but the v2.9.0 grouping delivers you nothing until you upgrade — don't put it on a roadmap as a user-facing win.
• You need custom CP navigation beyond a section/name declaration, or custom email shell logic beyond opt-in/opt-out; both APIs are intentionally narrow.

How to Pitch It (Stakeholders)

For executives: Two low-risk maintenance releases in the same window. v2.9.0 tidies where our admin settings appear in the Control Panel, so the Settings menu stays organized as we add capability. v2.9.1 fixes a customer-visible defect: branded emails that already carried their own header and footer were being framed a second time, which made them render wider than a phone screen. The fix is opt-in per template, so nothing changes unless we annotate it, and there are no migrations, no config changes, and no breaking changes. Both can ship in a normal release window and both degrade safely on older installs. The only follow-up with real owner-time attached is deciding which templates should keep the branded shell.

For engineering: v2.9.1 adds a branded => false key to the array a caller's fallback returns from EmailTemplates::resolve(); the body is returned as-is and is not re-wrapped in the branded shell. Absent the key, behaviour is unchanged — no feature flag, no conditional needed on our side. This is the correct seam for self-contained marketing templates but does nothing for templates we don't annotate, so the work is an audit of email rendering call sites, not an upgrade step. v2.9.0 remains: settingsNavParent() returning [section, name] renders settings as the sub-item "Einstellungen" under the addon's own CP entry with statamic-brand-context >= 1.16, and navigation-less addons share an "Addon-Suite" page under Settings. Three follow-ups: (1) confirm brand-context version per environment so the new settings layout is actually visible where we expect it; (2) annotate self-contained templates with branded => false and add a narrow-viewport render test to catch double-framing regressions; (3) refresh screenshots, template previews, and support macros that reference the old settings location or old email framing.