Statamic Position Fieldtype Laravel Package

Product Decisions This Supports

• Feature validation for visual content editing: The fieldtype provides a simple x/y coordinate picker inside Statamic’s control panel, which can support low-effort experiments around image hotspots, focal-point selection, annotated diagrams, banner cropping, or map-pin placement. A PM can use it to test whether editors actually need visual positioning before committing to a custom build.
• Build vs. buy vs. borrow: With one star, zero dependents, and no release since August 2020, this is not a strategic dependency. The realistic decision is borrow/adapt: audit the addon, vendor or fork it, and treat it as a starting point rather than a maintained platform component.
• Roadmap de-prioritization: If the only requirement is “let editors click a point on an image and save coordinates,” this package can remove that item from the custom-development backlog. That frees engineering capacity for higher-value work.
• Content-ops autonomy: Editors can position content visually instead of relying on hard-coded coordinates or developer intervention, which supports decisions about editorial workflows and CMS usability.
• Use-case fit: Best suited to simple single-point coordinate capture. Poor fit for multi-marker maps, geospatial search, accessibility-critical interactions, or complex annotation tools.

When to Consider This Package

Consider it when:

• The project is on a compatible Statamic version (likely Statamic 3-era) and the team is comfortable verifying compatibility in a sandbox.
• The need is narrowly scoped: capture or preview an x/y position on an image or canvas.
• Engineering is willing to fork, vendor, test, and own the code.
• The alternative is a custom fieldtype that would take more than a few days to build.
• The feature is experimental or internal-facing, where a stale dependency is tolerable.

Look elsewhere when:

• The project requires Statamic 4/5 support, active maintenance, security patching, or vendor SLAs.
• The feature is customer-facing and accessibility, keyboard support, or responsive behavior is critical.
• Requirements include multiple markers, geocoding, map providers, or spatial queries.
• The team cannot absorb maintenance risk or lacks PHP/Laravel capacity to audit the addon.
• A simpler solution exists: percentage-based focal-point fields, CSS object-position, or a maintained first-party fieldtype.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, low-commitment way to test visual positioning in the CMS without funding a custom build. It is not a strategic platform bet—adoption should be framed as a prototype or narrow feature enabler, with an explicit plan to fork and maintain if it proves valuable.

For engineering: The addon is small and auditable, making it a reasonable starting point for a coordinate-picker fieldtype. The risk is maintenance: one star, no dependents, and no release since 2020. Recommend vendoring or forking, adding tests, pinning versions, and documenting ownership before using it in production.

For product: Use it to unblock editor-facing positioning features quickly, then validate demand. If the feature graduates from experiment to roadmap commitment, replace or harden the implementation rather than scaling on an unmaintained dependency.