Statamic Position Fieldtype Laravel Package

Technical Evaluation

Architecture fit. This is a Statamic 3 Control Panel addon, not a general Laravel package. Its shape is the standard Statamic addon contract: a service provider that registers an addon manifest, a PHP Fieldtype subclass, and a Vue component that renders in the CP. It introduces no database tables, no migrations, and no queue or event surface — position is derived from existing collection/structure ordering. That makes it architecturally cheap: it sits entirely inside the content-modeling layer and does not touch application domain code, auth, or persistence. For a Statamic-based stack this is a near-zero-blast-radius component.

Integration feasibility. Mechanically trivial — composer require rias/statamic-position-fieldtype, then add the handle to a blueprint. The work is not integration; it is resuscitation. The package was last released 2020-08-20, targeting Statamic 3.x and the Vue 2 CP. Statamic 4 and 5 moved the CP to Vue 3/Inertia and bumped the Laravel baseline to 10/11, so the Composer constraint will block install and the CP asset will not register even if forced. Feasibility for a modern stack is therefore "vendor and port," not "install."

Technical risk. High, concentrated in three places:

• Abandonment. Single author, no release in ~5 years, no CI, no visible test suite. Bus factor of one, already realized.
• Zero validation signal. 1 star and 0 dependents means no downstream users to mine for bug reports, no forks carrying patches, and no evidence the edge cases were ever hit in production. The 1.705 score reflects that; the 17.81 opportunity score is the more interesting number — it says the capability (explicit sibling-position selection in the CP) is under-served, not that this artifact is good.
• CP API drift. Vue 2 → Vue 3 is the hard break. The PHP Fieldtype base class has been comparatively stable across Statamic 3→5, so the port is front-end-dominant — days, not weeks, but not zero.

Key questions for the spike.

1. Does selecting a position write the order of siblings on save (a side effect on publish), or does it only set a numeric field that templates must sort by? The former is a concurrency hazard; the latter is a display concern.
2. How are siblings scoped — collection-wide, within a parent page, per-site? Multi-locale and multi-site behavior is the most likely silent bug in a 2020 addon.
3. Is the option list computed on every CP render (N+1 sibling queries), and what is the ceiling on collection size?
4. Does it support structures/nested pages, or only flat ordered collections?
5. License terms — confirm it permits vendoring and modification before we fork.

Integration Approach

Stack fit. Clean fit for a Laravel + Statamic application, with the caveat that "fit" depends on which Statamic major you are on. On Statamic 3 (Laravel 8/9) it installs as-is and is low-risk. On Statamic 4/5 (Laravel 10/11) it requires a port and should be treated as an internal component, not a dependency.

Migration path. Two viable routes:

• Vendor and port (recommended). Copy the source into the repo as a local path repository or an addons/ directory under your own namespace. Update the statamic/cms constraint, port the Vue 2 component to the Vue 3/Inertia CP conventions, add a smoke test that asserts the fieldtype registers and its options resolve. Effort: roughly 2–5 dev-days for someone fluent in the Statamic CP; the PHP surface is small.
• Reimplement against core. If the port reveals deep coupling to removed CP APIs, the fallback is a thin custom fieldtype backed by an integer field plus an orderBy in the query layer. Loses the "insert at position N" affordance but eliminates the fork obligation.

Do not take a hard dependency on the abandoned upstream via composer require and hope. That guarantees a broken build at the next Statamic upgrade with no upstream fix path.

Compatibility. Verify PHP 8.1+ against the fieldtype's type hints, and audit any use of Statamic:: facade methods or CP asset registration APIs that changed between 3.x and 5.x. The front-end component is where the real breakage lives.

Sequencing.

1. One-day spike: fork, bump constraints, load the CP, confirm the fieldtype renders and returns options.
2. Decide port-vs-reimplement based on spike findings.
3. Pilot on a single low-traffic blueprint; validate position semantics against editor expectations.
4. Only then roll out to content collections editors actually touch daily.

Operational Impact

Maintenance. You become the maintainer on day one. The surface is small — a PHP class and a Vue component — but it is a CP component, so it inherits every Statamic major upgrade as a maintenance event. Budget a recurring line item, not a one-off.

Support. None upstream. No issue triage, no security advisories, no CVE feed. Internal ownership, internal runbook, and a documented "this is a fork" note in the repo are the mitigation. Given zero dependents, there is also no community to consult when it breaks.

Scaling. Risk scales with sibling count. If the option list enumerates all siblings on every CP render, collections in the low thousands will produce slow editor pages and heavy query volume; above a few hundred siblings it likely needs pagination or a search-backed picker. Runtime cost on the delivery side is nil if position is stored as a plain integer and sorted in the query — that path is cheap and cacheable.

Failure modes.

• Silent CP breakage after a Statamic upgrade — the field type fails to register, the field renders empty, content saves with no position. Highest-probability failure, and it fails quietly.
• Concurrent position writes — two editors inserting at position 3 simultaneously produce duplicate or gapped positions. No unique constraint exists because position is derived; de-duplication logic must live in your code.
• Stale positions on out-of-band changes — programmatic entry creation, imports, or API writes bypass the fieldtype, leaving gaps. Templates must sort defensively (orderBy('position') with a stable tiebreaker on id/date).
• Multisite drift — if sibling scoping is locale-naive, positions leak across sites.

Ramp-up. Low. A mid-level developer familiar with Laravel and either Vue 2 or 3 can read the entire source in an afternoon. The real cost is context, not complexity: someone must own the fork, know it is a fork, and remember to re-validate it at each Statamic major.

Recommendation. Treat this as a reference implementation, not a dependency. The opportunity score says the capability is worth having; the maturity signals (1 star, 0 dependents, 5 years stale) say do not inherit the maintenance. Fork it, port the CP component, keep the PHP surface if it survives the spike, and be prepared to fall back to a custom integer-plus-sort field if the port cost exceeds roughly a week.