Statamic Widget Newest Users Laravel Package

Product Decisions This Supports

• CMS/platform upgrade sequencing. "Statamic v5 support" is not a feature bullet — it is an upgrade unblocker. Statamic 5 requires PHP 8.2+ and Laravel 11, so this release is the gate between "we can move the content platform forward" and "this addon pins us to a soon-to-be-unsupported stack." That directly informs the timing of the Laravel 11 / PHP 8.2 migration on the roadmap.
• Build vs. buy for content capabilities. Addons in the Statamic ecosystem typically wrap a narrow capability (fieldtypes, integrations, workflow tooling). A maintained v5-compatible release is evidence the vendor intends to keep pace; a missing v5 release is evidence you will be writing and owning that code yourself. Use this signal to decide whether to keep paying/depending or absorb the scope in-house.
• Roadmap confidence for content-driven surfaces. If any planned work — marketing site rebuild, docs portal, multi-site/localization rollout, editorial workflow changes — sits on Statamic, this release determines whether those items can ship on a supported platform or must be re-scoped around a legacy version.
• Vendor/concentration risk review. Each addon that clears a major-version bump reduces the "orphaned dependency" count in the platform. Worth tracking as a portfolio metric alongside the upgrade plan.
• Use cases this unlocks or protects: content-managed marketing and docs sites, multi-site/localized content, editorial team workflows, and any customer-facing surface where editors, not engineers, own the copy.

When to Consider This Package

Adopt or retain when:

• You are on Statamic (or evaluating it) and this addon provides functionality you would otherwise build — check core and first-party addons first, since a surprising amount of what third-party addons cover gets absorbed upstream over time.
• You are planning or mid-flight on a Statamic 4 → 5 upgrade; this release is a prerequisite, not an optional nice-to-have.
• You need version parity: the addon should track Statamic majors within a reasonable window of the Statamic release, not months behind.
• The maintainer is responsive and the package has a test suite that runs against the current Laravel/PHP matrix.

Look elsewhere or plan to fork when:

• There is no v5 line and no maintainer signal — you will be carrying a compatibility patch through every future upgrade.
• The functionality is thin (a fieldtype, a small UI affordance) and cheaper to reimplement than to track.
• You require a commercial SLA, security disclosure process, or long-term support guarantees the package does not offer.
• Caveat on this release specifically: the note is a single line. It does not state whether v1.2.0 is a breaking change for existing v4 users, whether v1.1.x remains supported for Statamic 4, what the migration path is, or what the test coverage actually is. Treat "supports Statamic v5" as a claim to verify in a spike branch, not a fact.

How to Pitch It (Stakeholders)

For executives: This release keeps one of our content-platform dependencies on a currently supported version. That matters because unsupported dependencies are what turn routine upgrades into emergency projects — they force either an expensive fork or a rushed migration on someone else's schedule. The cost here is a dependency bump and some regression testing; the cost of not having it is being locked out of platform and security updates, with the remediation work landing unpredictably. Low spend, removes a known blocker from the upgrade path.

For engineering: v1.2.0 adds Statamic 5 support, which implies PHP 8.2+ and Laravel 11 compatibility. Before we commit: confirm whether v4 support continues in a maintained branch, read the changelog for behavior changes rather than trusting the one-line note, and validate in a throwaway branch against our actual content model — addons commonly "support" a major version while subtle behavior shifts (fieldtype output, query scoping, caching) surface only under real data. Budget a half-day of verification, not a half-hour. If the package is on our critical path, we should also decide now whether we are comfortable being one maintainer-absence away from owning it.