Statamic Reverse Relationship Laravel Package

Technical Evaluation

Package snapshot (v2.1.2): A Statamic 5 addon (cboxdk/statamic-reverse-relationship) that ships a custom Control Panel fieldtype for resolving reverse relationships between entries. It is distributed via Composer with pre-built frontend assets and includes Vue 2 CP components.

Architecture fit

• Fits the standard Statamic addon contract: registered fieldtype + Vue 2 CP component, installed into an existing Laravel app. No new infrastructure, no external services, no database migrations implied.
• Value is confined to the editorial layer (blueprint configuration and CP rendering). It is not on the request-serving hot path for the public site unless templates explicitly traverse the reverse relationship.
• Assumes Statamic 5's package layout — the fix moving @statamic/cms from resources/dist-package to packages/cms confirms this addon is pinned to the Statamic 5 toolchain and is not validated against Statamic 4.

Integration feasibility

• Low ceremony: composer require, then add the fieldtype to a blueprint via the CP. The v2.1.2 dist rebuild means the addon now works out of the box on Composer installs without a local npm run build, which removes the single largest adoption blocker for teams without a Node toolchain.
• No migration script, no schema change, no data backfill described. Existing relationship data is read, not written.
• Multi-site, localization, and large-dataset behavior are undocumented in the release notes and must be validated independently.

Technical risk

• Config-corruption regression (now fixed, but with residual state): v2.1.1 emitted the Vue 2 input event instead of update:value, causing field: null to be persisted into fieldtype configuration. The fix stops new corruption; it does not retroactively repair blueprints already saved with a null field. Any environment that ran v2.1.1 and saved the fieldtype config needs a manual audit.
• Fresh-install build failure (now fixed): the stale @statamic/cms path broke npm install/build for anyone building from source. This was primarily a contributor/CI concern; consumers were shielded only if dist assets happened to be current.
• Committed dist assets: the addon now relies on checked-in build output. This is convenient but opaque — consumers cannot verify the bundle matches source, and asset/JS drift after upgrade is a real failure mode (stale CP assets cached by browsers or by Statamic's asset publishing).
• Vue 2 dependency: the CP component is bound to Statamic's Vue 2 runtime. Future Statamic CP modernization is a standing compatibility risk for this addon specifically, since the bug fixed here was a Vue 2 event-contract issue.

Key questions

1. What is the supported Statamic/Laravel/PHP version matrix, and is Statamic 4 explicitly unsupported?
2. Do blueprints saved under v2.1.1 with field: null need a documented repair procedure, and is there a detection command?
3. How is the reverse lookup executed — Statamic's Stache index, a query builder call, or an in-memory scan? This determines behavior at scale.
4. Is multi-site/multi-locale reverse resolution supported, and how are cross-site relationships scoped?
5. What is the maintenance posture (single maintainer, release cadence, issue responsiveness) and license terms?
6. Are dist assets reproducible from a tagged commit, and is there CI that verifies bundle/source parity?

Integration Approach

Stack fit

• Requires: Laravel app running Statamic 5, Composer-based deploys, CP access for blueprint editing. No Node toolchain required as of v2.1.2.
• Conflicts only if another addon registers a similarly named fieldtype or overrides the same CP asset namespace — worth a quick namespace check in the target install.

Migration path

• New adoption: composer require cboxdk/statamic-reverse-relationship:^2.1 then php artisan statamic:assets:publish (or equivalent) and clear the CP cache. Add the fieldtype to a non-critical blueprint first.
• Upgrade from 2.0.x: low risk; patch-level, no API or config-shape changes signalled.
• Upgrade from 2.1.1: treat as mandatory. After upgrading, open every blueprint that uses this fieldtype and confirm the configuration field is populated and saves correctly.
• No database migration, no content backfill, no template changes required.

Compatibility

• Pin to ^2.1.2 rather than ^2.0 so the broken 2.1.1 window cannot be resolved by a fresh install of a loose constraint.
• Verify the app's Statamic minor version against the addon's statamic/cms constraint before rollout; a Statamic upgrade should be sequenced after, not simultaneously with, this addon upgrade.

Sequencing

1. Inventory current usage: which blueprints/fieldtypes, which environments, current installed version per environment.
2. Upgrade to 2.1.2 in local/staging; rebuild caches; verify CP asset load (hard refresh, check console for missing bundles).
3. Audit and repair any blueprint configs authored during the 2.1.1 window.
4. Functional test: create/edit an entry, verify reverse-related entries resolve correctly in the CP and in any front-end template using the field.
5. Promote to production; re-verify CP behavior post-deploy behind any CDN/browser caching layer.
6. Only then consider broader blueprint adoption.

Operational Impact

Maintenance

• Low ongoing surface: one Composer dependency, no scheduled jobs, no external services, no schema. Upgrade cadence should track Statamic major/minor releases, since the addon is tightly coupled to the CP's Vue 2 component API.
• Because dist assets are committed, upgrades are not purely a lockfile change — expect to re-publish assets and bust CP caches as part of the release runbook.

Support

• Small, single-vendor addon (cboxdk). Expect community-grade support: GitHub issues, no SLA. Budget for the possibility of forking or replacing the fieldtype if the maintainer goes dormant — the functional scope is narrow enough that an in-house replacement is feasible if the data model is understood.
• Internal ownership should sit with the team that owns the CMS blueprints, not a general platform team.

Scaling

• The primary scaling question is unresolved from release notes: whether reverse lookups use Statamic's indexed Stache or a query per render. On large content sets (tens of thousands of entries) with many relationships, an unindexed lookup in a CP listing or a front-end loop is the most likely performance cliff.
• Recommended mitigation: benchmark against production-sized content before broad rollout; if the field is used in front-end templates, cache the resolved results rather than resolving per request.
• Multi-site installs multiply lookup scope; validate before enabling on a shared blueprint across sites.

Failure modes

• Silent config loss: fieldtype configuration saved with a null field — the exact 2.1.1 defect. Symptom is a fieldtype that renders but resolves nothing, with no error. Detection requires a blueprint audit, not monitoring.
• Stale CP assets: after upgrade, cached JS can leave editors on the old component, reproducing the null-save behavior in a "fixed" install. Mitigate with cache-busting and a post-deploy smoke test.
• Statamic upgrade breakage: a CP component API change makes the fieldtype render blank or throw in console. Symptom is CP-only; public pages usually unaffected unless templates depend on the field.
• Query cost: slow CP entry-editing or slow template renders on large datasets.
• None of these are monitored by default — there is no telemetry. Detection depends on editor reports and CI smoke tests.

Ramp-up

• Developer effort: hours, not days — Composer install, one blueprint change, one smoke test. No new concepts beyond standard Statamic fieldtype configuration.
• Editor effort: minimal; the field behaves like a read-only relationship view. Brief documentation of "what this panel shows" is worthwhile to prevent editors mistaking it for an editable relationship field.
• Operational effort: add two items to the release checklist — re-publish CP assets, and audit blueprint configs after any addon version change.

Recommendation: Adopt v2.1.2 as the minimum acceptable version (2.1.1 should be treated as broken). Roll out behind a staging validation of blueprint config integrity and lookup performance on production-sized content. Track Statamic upgrade notes as a standing review trigger, given the Vue 2 coupling.