Statamic Element Picker Laravel Package

Product Decisions This Supports

• CMS platform upgrade planning (Statamic 4 → 5): v1.1.0 removes this addon as a blocker for a Statamic 5 migration. If Statamic 5 is on your roadmap, this is the version to pin; if you are staying on Statamic 4, v1.0.1 remains the relevant line and no action is required.
• Build vs. buy for editorial UI: An element picker (a fieldtype for selecting/relating elements inside the control panel) is a small, well-bounded piece of editor UX. Adopting a maintained package avoids spending engineering days re-implementing a fieldtype, its Vue component, and its validation/indexing behaviour.
• Content modelling and authoring-experience scope: Supports decisions about how editors relate content (entries, assets, or other elements) inside Statamic. Relevant when scoping editorial workflow improvements where "pick existing content instead of re-typing it" is the requirement.
• Dependency footprint and support matrix: The release confirms the package tracks current Statamic majors. This feeds into your supported-version matrix and into any decision to standardise addons on packages that ship compatibility releases promptly rather than lagging a major behind.
• Not a differentiator: This is table-stakes tooling, not a product capability. Treat it as infrastructure — the decision is "cheap to adopt, cheap to replace," not "strategic investment."

When to Consider This Package

Consider it when:

• You run Statamic 5 (or are upgrading to it) and need an element-selection fieldtype in the control panel; v1.1.0 is the first release that supports it.
• Your team is small and you would rather compose existing fieldtypes than maintain a custom one; the functional surface is narrow enough that adoption cost is low.
• You can tolerate a single-maintainer, community addon — verify licence, open-issue count, test coverage, and commit cadence before committing.
• You are comfortable pinning a version and having a fallback: the underlying need (select an element) can be met with Statamic's built-in relationship fieldtype if the addon goes stale.

Look elsewhere or build in-house when:

• You need guaranteed long-term support, SLAs, or security responsiveness — a solo-maintainer addon is a supply-chain consideration you should log, not ignore.
• Your requirements exceed a picker (complex querying, permissions per selectable element, custom search backends). Evaluate whether native relationships or a custom fieldtype is a better fit before layering a dependency.
• You are on Statamic 3 or earlier, or on PHP/Laravel versions outside the Statamic 5 support matrix — check the composer constraints; v1.1.0 likely raises minimum platform requirements alongside the Statamic bump.
• The addon duplicates functionality already available in core; prefer core to reduce surface area.

Release-specific read: v1.1.0 is a compatibility release with no new user-facing capability and, per the notes, no stated breaking changes for existing users. The only material question is whether the composer constraints for v1.1.0 also raise your PHP/Laravel floor — confirm before adopting, since that can cascade into wider upgrade work.

How to Pitch It (Stakeholders)

To executives: This is a small, free addon that lets editors link to existing content from a picker instead of re-entering it — a modest authoring-quality improvement at effectively zero cost. The new release's significance is not new features but that it keeps us current: it now supports Statamic 5, so it will not hold up a platform upgrade. Risk is low but non-zero: it is maintained by an individual contributor, so we should treat it as replaceable and avoid depending on it for anything critical.

To engineering: v1.1.0 adds Statamic 5 support; no new features and no announced breaking changes. Before merging: verify the composer constraints (PHP/Laravel minimums may have moved with the Statamic 5 bump), run the existing test suite against Statamic 5 if we are upgrading, and pin the version. If we are not on Statamic 5, there is no reason to move off v1.0.1 yet. Flag maintenance risk — single maintainer, small dependency — and confirm the fallback to Statamic's native relationship fieldtype is viable if the package is abandoned.