Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Nova Link Field Laravel Package

khalin/nova-link-field

A Laravel Nova field for adding clickable link inputs to your resources. khalin/nova-link-field makes it easy to display and manage URLs alongside model fields in Nova admin panels.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Whether to invest in back-office operator UX at all. Clickable links instead of raw URL text is a small but real efficiency win for support, ops, and content teams working out of Nova — supplier portals, campaign pages, documentation, external records. The decision here is "is this worth any effort?" The answer is yes, but the effort should be measured in hours.
  • Build vs. buy for a narrow, disposable capability. The honest comparison is not "package vs. nothing," it is "an unmaintained 2020 package with 31 stars, zero dependents, and a single release" versus "a Link field extending Nova's base Field plus a ~20-line Vue component." Both land in the same place functionally; only one of them is a permanent line item in your dependency inventory. Framing the package as reference implementation rather than dependency is the highest-value decision this review supports.
  • Roadmap scoping: one-off tweak or standardized pattern? Decide early whether clickable links are a single-resource convenience or a house style applied across ten or fifteen resources. If it's the latter, the target/rel/sanitization policy must live in one wrapper class, not be copy-pasted into every fields() method — that's the difference between a two-hour change and a recurring audit.
  • Dependency risk triage. One release (2020-05-17), one maintainer, no dependents, no service provider shipped. This belongs in the "vendor/internal artifact, named owner, quarterly review" bucket — or, more likely, the "do not adopt" bucket. It should never enter via a casual composer require inside a feature branch.
  • Security and data-quality scope for admin-supplied URLs. A field whose entire job is rendering URLs must reject javascript: and data: schemes and emit rel="noopener noreferrer" with target="_blank". Neither behavior is documented here, and the maintainer has been inactive since 2020. That forces an explicit decision: verify and patch in a fork, or avoid the dependency and own the render path from day one.
  • Write-path safety. If the Vue component is display-only, exposing it on forms risks silently blanking the underlying column on save. The production-safe pattern — Link on index and detail, editable Text/URL field on forms — needs a product decision, not a developer workaround discovered in production.

When to Consider This Package

Consider it when:

  • You are already on Laravel Nova 2.x/3.x (Laravel 6/7, PHP 7.2–7.4 era) and composer require resolves cleanly on the first attempt, without widened constraints or --ignore-platform-reqs.
  • The use case is internal-only and low-criticality: external system links, documentation, campaign pages, supplier portals, reference records.
  • You have reviewed src/Link.php and resources/js/components/ and confirmed the component escapes labels safely (v-text, not v-html) and handles target/rel correctly.
  • You have verified index, detail, and form views individually on a throwaway record — and confirmed the form view either renders an input or is excluded via ->exceptOnForms().
  • You want a short-term accelerant or a working reference to copy from, and someone is willing to fork and own it.

Look elsewhere or build in-house when:

  • You are on Nova 4 or 5. The 2020 release predates the Vue 3 / Inertia rework and the Nova::script(...) asset registration model — this package ships no service provider, which is itself the failure mode. Expect resolver rejection, a blank field, or a JS mount error that degrades the entire resource page.
  • The links are customer-facing, business-critical, or subject to accessibility and security review.
  • You need maintained support, active releases, or any ecosystem validation (zero dependents means nothing gets fixed upstream — ever).
  • Nova's native URL field, a Text field with a resolveUsing/displayUsing callback, or a small in-house field already covers the need.
  • You need richer link UX: truncation, copy-to-clipboard, icons, meaningful sorting, or filtering on the URL column. This package is an anchor and nothing more.
  • The team cannot absorb maintenance after a Nova upgrade — which, given the release history, is a question of when, not if.

Bail condition, stated plainly: if the install doesn't resolve cleanly on your stack, stop. Don't widen constraints, don't inline-alias, don't replace. The blast radius of a bad field is small — delete one line from fields() — but the maintenance tax is permanent, and the in-house replacement is genuinely a few hours of work.

How to Pitch It (Stakeholders)

For executives — the one-line version: This is a tiny UI convenience for internal admin screens, not a platform capability. It is safe to skip, and the cost of recreating it ourselves is measured in hours, not sprints.

The recommendation: Do not adopt khalin/nova-link-field as a production dependency. Treat it as a reference implementation. If clickable links are worth having — and for support and ops teams they usually are — build a small internal Link field in roughly half a day, with URL-scheme validation and safe target/rel handling baked in. You get the same operator experience, zero version risk, and code your team actually owns.

Why not just install it? Three reasons, in order of weight:

  1. It is effectively abandoned. Last release May 2020, one maintainer, no dependents, no service provider. There is no upstream to receive fixes from — anything you adopt becomes an internal artifact on day one, whether you plan for that or not.
  2. The compatibility cliff is real and the failure mode is ugly. On Nova 4/5, the worst case isn't a missing field — it's a JavaScript mount error that degrades the whole resource page. That means trial on one low-traffic resource, never a batch rollout.
  3. The security work is on us regardless. Undocumented URL-scheme handling and unverified rel="noopener noreferrer" on a field that renders admin-pasted URLs from external sources. That's a patch in a fork you didn't want to maintain.

For engineering — what "build it" concretely means: a subclass of Laravel\Nova\Fields\Field with a resolver callback for normalization (bare domains → https://, mailto:/tel: opt-in per field) and a small Vue component that escapes labels, rejects non-HTTP schemes, emits safe rel attributes, and renders nothing for null values rather than <a href="">. Keep the editable Text/URL field on forms and show the Link only on index and detail.

The ask: a half-day spike to ship the internal field, or — if you're already pinned to Nova 2/3 and want to move faster — a time-boxed trial of this package on a single resource with the exact version pinned, a named owner in the dependency inventory, and a fork plan in hand. Either way, the outcome is the same: we own the code path that renders URLs in our admin panel. The only variable is whether we start from a clean file or a 2020 fork.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
skyraptor/chatter
edlugz/sasapay
abbasudo/artisan-route
mirvan/ippanel
ignibyte/aic-framework
glavweb/data-schema-bundle
glavweb/datagrid-bundle
tacticmedia/scim-server
uni-method/frame
neika-ai/sdk
adachsoft/php-code-style
pharaonic/laravel-notification-dependencies
beautinow/translug
dev-brainiac/bot-cloaked
octoberrain/html
octoberrain/extension
octoberrain/exception
octoberrain/contracts
adachsoft/api-version-bundle
cgv/localized-resource