Statamic Link It Laravel Package

Product Decisions This Supports

• Editorial linking UX as a first-class product surface. Link-it consolidates "link to an entry / an asset / an external URL / a mailto / an anchor" into a single Statamic fieldtype with a consistent stored shape. That makes "how do editors create links?" a product decision you can standardize on rather than a per-project implementation detail.
• Build vs. buy for a commodity fieldtype. A custom polymorphic link field (target type, target reference, label, target attribute, validation) is roughly 2–5 engineering days plus permanent maintenance. Adopting this package removes that line item from the roadmap and frees capacity for differentiators.
• Content model / CMS architecture decisions. Because the field stores a structured link rather than a hardcoded URL string, it enables downstream product features — link labels rendered per-locale, internal vs. external link treatment, future broken-link auditing, redirect-on-unpublish behavior — without a content migration.
• Multisite and content-reuse roadmap. A single field type that resolves targets across entries, taxonomies, and assets is a prerequisite for "link once, reuse everywhere" content patterns; it de-risks later work on shared components and cross-site navigation.
• Use cases to scope for: marketing landing pages with mixed CTA targets, documentation/help-center cross-linking, navigation and footer link sets, press/asset download links, campaign URLs with tracking attributes, and any Bard/Replicator block whose entire purpose is "a button."
• Not a differentiator. Treat this as infrastructure hygiene, not a product bet. The decision it really informs is "can we ship the content features on the roadmap without a custom field plugin in the critical path?"

When to Consider This Package

Consider it when:

• The stack is Statamic on Laravel (this is hard-coupled to the Statamic addon/fieldtype API — it is not a generic Laravel package).
• Editors repeatedly need to link to heterogeneous targets and today you have two or three ad-hoc fields (url, entry_id, asset) that the front end has to disambiguate.
• You want structured link data in the content layer now to avoid a migration later when you add analytics, localization, or broken-link checks.
• You are comfortable with a small, single-maintainer addon whose failure mode is contained: content is stored in YAML, the fieldtype is replaceable, and a fork is cheap.
• You need something already shipping — the recent release cadence (latest 2026-08-12) suggests active maintenance rather than an abandoned experiment.

Look elsewhere or build in-house when:

• You are not on Statamic, or you are on a version the addon doesn't support — verify compatibility with your exact Statamic major before committing.
• You need link governance: broken-link scanning, redirects, click analytics, approval workflows, link inventory reporting. Those belong to a separate service or your own layer; this package only captures intent.
• You depend on enterprise support, SLAs, or a security review process. Ten stars and zero dependent packages is essentially zero ecosystem evidence; there is no community backstop if the maintainer steps away.
• Link semantics are domain-critical and divergent (e.g., commerce deep links with SKU/price parameters, signed URLs, per-market routing). A bespoke field with explicit validation will beat a general-purpose one.
• Your Bard/Redactor/Markdown editor linking already covers 90% of cases and the remainder is a handful of fixed fields — the added abstraction may not pay for itself.

Adoption gate (do this before committing): one spike on a real site — install, model a representative page, render internal/external/asset links through your existing Antlers/Blade partials, and confirm the stored payload is stable enough to build a resolver helper on top. Treat the low star count as "unproven, so prove it cheaply" rather than as a disqualifier.

How to Pitch It (Stakeholders)

For executives (30 seconds):

We have a recurring, low-glamour cost: every Statamic site we build reinvents "make a link" — a URL field here, an entry picker there — and then the front end has to guess which one it got. This addon replaces that with one standard field, so editors pick a target once (page, asset, or external URL) and it renders consistently. It's free, it's small, and it removes a few engineering days from every content-heavy build. The real risk is that it's maintained by one person and barely used in the wild — but the exposure is limited: content is stored in plain files, the field is swappable, and a fork would take days, not months. Recommendation: adopt on new builds, pilot on one, and keep a one-page fallback plan.

For engineering (the substance):

• Statamic fieldtype addon, Laravel-native, installs via Composer; no service dependencies, no database schema, no runtime infrastructure.
• Value is standardization: one field, one stored structure, one rendering path — replacing N bespoke fields and their divergent edge cases (external vs. internal URL resolution, asset URLs, target/rel attributes, empty-label fallbacks).
• Explicitly out of scope: link validation, redirect management, analytics. We should not expect those from it and should plan our own resolver/helper layer if we need them.
• Risks to price in: bus factor of one, no dependent-package signal, and version compatibility with our Statamic major. Mitigate with a pinned version, a thin internal wrapper around the field's output (so the addon is never called from templates directly), and a documented fork path.
• Ask: approve a one-sprint spike on an upcoming build; success = editors use it without training and the resolver wrapper covers all three target types with no template branching.