Statamic Embed Fieldtype Laravel Package

Product Decisions This Supports

• Silent-staleness risk in refresh-driven flows. Patch 1.3.2 fixes the refresh parameter not being honored, which is the class of bug that produces "the data didn't update and nobody noticed" incidents. If your roadmap includes user-facing refresh actions (dashboard reload, "sync now" buttons, tenant/config reload, cache-busting on API passthrough), this patch directly de-risks those features.
• Build vs. buy. A maintainer shipping a targeted correctness fix on a patch version is a positive maintenance signal. Use it as one input when comparing "adopt the package" against "build the refresh/invalidation logic in-house" — in-house workarounds for an unhonored parameter (manual cache clears, double-fetch, queued invalidation) are exactly the hidden cost that tips build-vs-buy decisions.
• Scope-cutting. Teams that had queued workaround tickets ("force refresh via secondary call", "add TTL fallback") can likely close them, freeing roadmap capacity for features rather than compensations.
• Not a feature decision. This release adds no new capability, no API surface, and no configuration. Do not plan roadmap items, demos, or customer commitments that assume new behavior in 1.3.2 — treat it strictly as a reliability patch.
• Adoption sequencing. Safe to fold into an upcoming maintenance window or the current sprint's dependency bump; it does not justify re-architecting a flow or re-running a design review.

Caveat for this assessment: it is derived from the 1.3.2 release alone. Treat the refresh/freshness framing as the confirmed signal and validate the package's wider surface (Laravel version support, cache drivers, concurrency behavior) before making a committed buy decision.

When to Consider This Package

Consider it when:

• Your product has any user- or system-triggered refresh/invalidation path where "did it actually refresh?" is a correctness question, not a cosmetic one — and you want that semantics supplied by the package rather than hand-rolled.
• You are on a supported Laravel/PHP version and can accept patch-level dependency churn during a normal maintenance cadence.
• You can pin the version (1.3.2 or a caret constraint that includes it) and add a regression test asserting the refresh parameter is honored end-to-end in your integration.
• You value maintainer responsiveness — a fast, narrow fix is evidence the parameter contract is being treated as a supported guarantee rather than an incidental detail.

Look elsewhere (or invest in evaluation first) when:

• You need a freshness SLA or formal guarantee. A patch note is not a contract; if correctness in a regulated, billing, or audit flow depends on refresh semantics, you need documented behavior and your own test coverage before adoption, and possibly a vendor with support terms.
• You cannot upgrade — if you are locked below a supported Laravel/PHP version, or pinned to an earlier line, you will not receive this fix and remain exposed to the staleness behavior.
• This fix is the entire basis of your confidence. One patch note tells you the parameter broke and now works; it says nothing about adjacent behavior (concurrent refreshes, driver differences, partial failures). If refresh is load-bearing, budget a short spike that exercises those paths.
• Your flow can tolerate eventual consistency anyway — an unhonored refresh was already harmless to you, so the patch is a routine bump rather than a decision point.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk patch release that fixes a parameter which was silently not being honored. In plain terms: when the product asked for fresh data, it may not have gotten it — and it now does. There is no new feature to sell, no migration cost, no licensing or vendor change, and no customer-visible commitment required. The upside is a reduced risk of stale-data incidents and the removal of planned workaround work; the cost is a routine dependency bump. The one thing to note is that it is a fix, not a guarantee, so any flow that depends on refresh behavior should carry a test.

For engineering: Upgrade to 1.3.2 and verify the refresh parameter is honored along your actual call paths — most importantly where the value is read, forwarded, or defaulted, since that is where it previously got dropped. Add a regression test that fails on 1.3.1 and passes on 1.3.2 so this cannot silently regress. Check whether any existing code compensates for the old behavior (manual cache clears, double requests, forced TTLs) and remove that scaffolding only after the regression test is green — leaving it in place will mask the parameter again and hide future breakage. No API or configuration changes are expected, so the diff review should be quick and the risk concentrated entirely in your own integration points.