Statamic Wrapped Laravel Package

Product Decisions This Supports

• Roadmap / platform-upgrade timing: This release is a compatibility hedge against an upstream Statamic change (statamic/cms#15495). If your roadmap includes a Statamic minor/major upgrade this quarter, treat the addon's v1.6.5 as a prerequisite rather than a follow-up — it removes a class of post-upgrade regressions before they reach users.
• Risk posture on silent failure modes: The bug described is not a crash — it's a quiet fallback to the config file, meaning appearance ("the look"), soundtracks, and the public-links toggle would drift back to defaults without any error. That is exactly the kind of defect that surfaces as "why did our branding change?" support tickets rather than a monitoring alert. This supports a decision to pin a minimum version in composer.json and to treat settings-persistence behavior as a release-gate test item.
• Build vs. buy: Reinforces buying/adopting rather than building. The addon owns a narrow but fiddly concern — Statamic settings-screen integration, per-package settings resolution, and config fallback semantics. Rebuilding this in-house means re-implementing upstream quirks you'd otherwise inherit for free.
• Feature decisions it enables: The settings surface implied by the notes (theming/appearance, soundtrack selection, a public-links sharing switch) maps to concrete product capabilities — branded media presentation, curated audio/playlist experiences, and opt-in public sharing of media. These are shippable customer-facing features without new backend work.
• Support & CS planning: Because the failure mode is a silent revert to config defaults, support runbooks should include "verify saved settings after any CMS upgrade" as a standard step, independent of this fix.

When to Consider This Package

Consider it when:

• You are on Statamic and need media/audio presentation — theming hooks, soundtracks/playlists, and a public-link sharing toggle — without building a bespoke addon.
• You want config-file-driven defaults with a settings-screen override, and can live with the fallback semantics that implies (config is the floor, the control panel is the override).
• You value upstream tracking: the maintainer is reading Statamic's issue tracker and shipping forward-compatible fixes before the upstream change lands. For a small team, that maintenance behavior is frequently worth more than feature breadth.
• Your release process can absorb patch-level upgrades with no migration steps — this release explicitly requires none, which keeps upgrade cost near zero.

Look elsewhere when:

• You are not on Statamic, or you are on a Statamic version outside the addon's supported range.
• You need a full DAM / media library (transcoding, renditions, rights management, CDN pipelines) — this is a presentation-and-settings layer, not an asset platform.
• You require vendor SLAs, security disclosures with timelines, or long-term support commitments; a single-maintainer package is a poor fit for that risk profile regardless of code quality.
• You need API-first or headless-only media delivery with no control-panel settings dependency.
• Your settings model must support multi-site / per-environment divergence beyond what config + package settings give you — validate this explicitly before committing.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a low-risk maintenance release for the media addon — a bug fix, no upgrade steps, no schema or data migration. Its significance is timing: Statamic is changing how addons read their saved settings, and this version makes our addon work correctly on both sides of that change. Without it, a future CMS update could have silently reset our saved appearance, soundtrack, and public-sharing settings back to defaults — no error, no alert, just a quiet behavioral change customers would notice. Adopting v1.6.5 now costs nothing and removes that exposure. It's also a useful signal about the vendor: they're monitoring upstream and shipping ahead of the break rather than reacting to it.

For engineering (concise): The addon now resolves its saved settings by package name rather than slug, matching how Statamic's own settings screen does the lookup. Prior versions (including the 1.6.4 workaround) relied on the slug-based path, which will return empty once statamic/cms#15495 ships — at which point the look, soundtracks, and public-links toggle would have silently fallen back to the config file. v1.6.5 is correct under both the current and upcoming behavior, which means no flag day and no coordinated deploy with the CMS upgrade. No upgrade steps, no config changes. Recommended actions: bump the constraint to ^1.6.5, and add a post-upgrade verification step to the release checklist that saved settings still override config after any Statamic bump — the failure mode here is silent, so it won't announce itself.