Statamic Super Location Laravel Package

Technical Evaluation

Package profile (inferred): A Statamic addon that registers a "super location" fieldtype — an augmented location/geo field for the Statamic control panel, typically wrapping a map provider, address geocoding, and lat/lng persistence on top of Statamic's native fieldtype API. It is a Laravel-ecosystem package by virtue of being a Statamic addon (service provider, config publish, CP asset registration), not a general-purpose Laravel library.

Architecture fit: Fit is narrow but clean. The package sits at the CMS layer, not the application domain layer. It attaches to entry/term/asset blueprints and emits coordinates and address metadata into content storage. That means it does not touch our domain models, queues, or APIs — low architectural blast radius. The trade-off is that location semantics live in CMS content rather than a queryable geo table, so any real geo-querying (radius search, proximity sort) will likely need an indexer or projection we own. Confirm whether the fieldtype persists structured values (lat/lng plus components) or a serialized blob; this determines whether we can index it without a custom transform.

Integration feasibility: Feasible, with one hard gate: Statamic 6. The v2.0.0 note mentions only "Add Statamic 6 support for super location fieldtype," and a major version bump paired with a single platform-support line strongly implies a compatibility break — most plausibly a raised floor (Statamic 6 / Laravel 11+ / PHP 8.2+) and correspondingly a dropped Statamic 5 line, possibly with Fieldtype class or CP asset API changes. That is the single most important fact to confirm before planning. If we are on Statamic 5 today, v2.0.0 is not adoptable and we should pin v1.x. If we are planning a Statamic 6 upgrade, this release is a prerequisite dependency and should be sequenced into that program rather than treated as a standalone upgrade.

Technical risk:

Key questions for the maintainer / spike:

1. What exactly breaks between v1.x and v2.0.0 — class names, config keys, stored value schema, or only the platform constraint?
2. Is Statamic 5 still supported on a v1.x branch, and for how long?
3. What are the minimum PHP / Laravel / Statamic versions for v2?
4. Does the persisted field value shape change, and is there a migration command or documented upgrade path?
5. Which geo/map providers are supported, and is an API key mandatory for CP rendering?
6. Is "super location" a distinct fieldtype from the package's other fieldtypes, and does Statamic 6 support extend to all of them or only this one?

Integration Approach

Stack fit: Assumes we run Statamic on Laravel. If our Statamic install is at v5, v2.0.0 is out of scope until a CMS major upgrade lands. If we are greenfield on Statamic 6, this is a straightforward composer require plus config publish plus blueprint wiring — days, not weeks. If we are mid-flight on a Statamic 6 upgrade, treat this as one line item in that program's dependency checklist.

Migration path: Two-track decision.

• Track A — stay on Statamic 5: pin ^1.0, no action on v2.0.0, monitor for a security backport. Record the pin rationale so it is not silently bumped by a composer update.
• Track B — move to Statamic 6: upgrade the CMS first (that is the real project), then adopt this package, then audit every blueprint using the fieldtype. Content migration — if the stored shape changed — must be scripted, dry-run against a staging copy of the database, and reversible. Do not attempt a combined "upgrade CMS and fieldtype and migrate content" cutover in one deploy.

Compatibility: Pin the package to an exact minor during rollout rather than floating ^2.0. Statamic addons commonly ship patch releases that adjust CP assets and fieldtype internals against the host CMS; a floating constraint on a fresh major is where CP breakage comes from. Confirm compatibility with our PHP runtime and any other addons registering CP assets (Vite/build collisions and duplicate map-library loads are the usual failure).

Sequencing:

1. Read the actual v2.0.0 diff and changelog (the release note is not sufficient evidence).
2. Confirm our Statamic version and the package's supported matrix.
3. Spike in a disposable branch/staging copy: install, wire one blueprint, author an entry, verify CP render and stored value.
4. If stored shape changed, write and dry-run the content migration.
5. Roll to staging, then production behind a maintenance window if a migration is involved.
6. Only then widen the composer constraint.

Operational Impact

Maintenance: Statamic addons track CMS majors, and CMS majors arrive on a cadence we do not control. Budget a recurring, low-but-nonzero maintenance line: a compatibility check each time we bump Statamic or Laravel, and a review of every addon major before adoption. Pin versions and let Renovate/Dependabot open PRs rather than auto-merging — auto-merge on a CMS addon major is how a CP breaks on a Tuesday.

Support: Expect maintainer-dependent support. A one-line release note for a major version is a documentation smell; verify there is an issue tracker with recent activity and a stated support policy for the prior major. If the package is single-maintainer with no v1 maintenance branch, treat Statamic 5 support as ending at v2.0.0 and plan accordingly. Identify an internal owner — this is a CMS-layer dependency, so it sits with whoever owns the Statamic install, not the platform team.

Scaling: Two axes. Authoring scale is fine — it is a CP fieldtype, load is per-editor, not per-request. Delivery scale is the concern: geo filtering and proximity search against CMS-stored field values typically means loading and filtering in PHP, which does not scale. If any roadmap item needs radius search, map clustering, or geo facets, plan a projection into a dedicated indexed store (SQL spatial column, Meilisearch/Algolia geo, or Postgres/PostGIS) fed by a content sync. Decide this before content volume grows, because retrofitting an index over years of authored entries is materially harder than starting with one.

Failure modes:

• CP degradation: the map widget fails to render if the geo provider is unreachable or the API key is missing, rotated, or over quota. Editors see a broken field on an otherwise healthy site. Alert on provider quota and surface a config health check.
• Silent data loss on save: a fieldtype that fails to hydrate on a schema change can overwrite coordinates with empty values. Back up content before the v2 rollout and diff a sample of entries post-migration.
• Constraint drift: a transitive composer update pulling a v2 patch that assumes a newer Statamic than we run. Mitigate with exact pins and a CI job that boots the CP.
• Key exfiltration: provider keys in config are readable by anyone with repo access. Use env vars and the CMS's encrypted config path; confirm whether the key is exposed to the CP front end (map keys usually are, and then need domain restriction).
• Abandonment: prior major left unsupported with no successor. Mitigation is the content migration path back to a plain field plus our own geo index — worth documenting before it is needed.

Ramp-up: Low for developers — composer install, publish config, add the fieldtype to a blueprint, set the provider key. Half a day including a staging verification. The real ramp-up cost is editorial: authors need guidance on address entry conventions and coordinate precision, and support will absorb "the map isn't loading" tickets that are almost always key/quota/browser issues rather than the package. Write a one-page runbook covering key rotation, quota monitoring, and the fallback behavior when the map fails. Also brief whoever owns the content model on the value shape, so downstream templates and any geo index are built against the right contract.

Recommendation: Do not adopt v2.0.0 on the strength of the release note alone. Confirm the Statamic version gate and the breaking surface first. If we are on Statamic 5, pin v1.x and revisit as part of a Statamic 6 program. If we are on or moving to Statamic 6, adopt it — but as a sequenced dependency inside that upgrade, with an exact version pin, a staging verification of the stored value shape, and a decision recorded now on whether geo querying will live in the CMS or in a projection we own.