Statamic Field Item Relationship Laravel Package

Product Decisions This Supports

• CMS upgrade gating: v2.0 is the Statamic 6 (Vue 3) compatible line. If Statamic 6 is on our roadmap, this addon's release status is a concrete dependency item — not a background task. If we're staying on Statamic 5, this release is not for us, and we should pin the 1.x line deliberately.
• Editor UX investment: The sibling-field value tracking fix replaces fragile DOM/component lookups with publish container values. This is a reliability decision, not a cosmetic one — it directly reduces "the relationship field shows the wrong thing after I reorder blocks" support tickets and QA cycles.
• Content modeling / build vs. buy: Justifies continuing to model intra-entry relationships (e.g. a block in a page builder referencing another set of items in the same entry) with this addon rather than commissioning a custom fieldtype. The maintenance signal here (Pest coverage) is thin but directionally positive.
• Data shape and downstream contracts: "Save as: Index" for simple string arrays changes what gets stored for a common content pattern. Worth a decision on whether we standardize on indexed arrays for programmatic consumers (API responses, static site builds) or keep the existing shape to avoid migration work.
• Roadmap sequencing: Any content-type redesign involving Replicator/Grid structures should be scheduled after the Statamic 6 + addon v2 upgrade, not before — otherwise we rebuild the same fields twice.

When to Consider This Package

Adopt when:

• The stack is Statamic, and the requirement is genuinely within-entry item relationships — one field pointing at sibling items rather than at separate entries.
• Editors are non-technical and need a picker UI instead of hand-keying IDs or slugs into a text field.
• You accept a community addon (single maintainer, small install base) and can absorb the risk of slow responses to future Statamic releases.
• You are moving to Statamic 6 and need this fieldtype to survive the Vue 3 transition intact.

Look elsewhere when:

• The real need is cross-entry or cross-collection relationships — Statamic's native Entries/Relationships field is the right tool and carries no third-party risk.
• You need a vendor SLA, security review, or long-term support commitment.
• You are on Statamic 4 or 5 and have no near-term upgrade plan — v2.0's platform jump makes it the wrong branch.
• Relationship sets are large enough to need search, filtering, or pagination in the picker; verify this before committing, as the release notes say nothing about scale.

Caveat to verify before committing: a major version bump alongside a framework-version jump almost always means the new constraint excludes older Statamic versions. Confirm the composer requirements and confirm that the reactive-tracking fix covers our specific field configurations — the new test suite covers the {{ fir }} tag, not the control-panel fieldtype behaviour that the headline fix touches.

How to Pitch It (Stakeholders)

For executives: A small, free community addon that lets editors link content blocks to one another inside a page — the kind of thing that otherwise generates a steady trickle of "the wrong item is showing" support tickets. The new release fixes a class of those bugs at the root and keeps us compatible with the next major version of our CMS. Cost is near zero; the decision is really about timing the CMS upgrade, not about budget. The main risk is dependency on a single maintainer, which we mitigate by pinning versions and keeping a native-field fallback in mind.

For engineering: v2.0 is a breaking, Statamic 6 / Vue 3 release. The substantive change is that sibling field values are now read from the publish container instead of via DOM/component lookups — more stable under reordering, conditionals, and nested components, and it removes a whole category of timing bugs. There's a new Save as: Index option affecting stored data shape for simple string arrays, so check for downstream consumers before enabling it. Test coverage has been added for the {{ fir }} tag only; the CP fieldtype remains untested. Recommended path: verify composer constraints, upgrade in a branch alongside the Statamic 6 bump, exercise the fieldtype in our most complex page-builder layout, and only then decide whether indexed-array storage becomes our standard.