Url Link Type Extension Laravel Package

Product Decisions This Supports

• Navigation/link-type extensibility in a CMS-backed product. This package answers a narrow but real product question: can editors point a nav item at an arbitrary URL (external site, campaign landing page, mailto:, tel:) rather than only at an internal page? If your roadmap includes a marketing-site or portal built on PyroCMS, this is the capability that unblocks editors from filing engineering tickets for every nav change.
• Build vs. buy vs. vendor-in. The package is a thin link-type implementation against the Navigation module's contract. The decision it most directly informs is not "should we install this?" but "should we copy this pattern into our own codebase?" — the code is a reference implementation of an extension point, and vendoring ~one class is cheaper than owning a dependency.
• Architecture bet: pluggable link types. Adopting this signals you're standardizing on the Anomaly Navigation module's link-type abstraction. That's a commitment with downstream consequences for how editorial content models links, how URL validation and sanitization are enforced, and how migrations/redirects are handled.
• Scope negotiation. Zero stars and zero dependents means you cannot treat this as a de-risked third-party component. The relevant product decision is whether URL link types are in scope for v1 or can be deferred behind internal page links.
• Editorial workflow requirements. Supports prioritization of features this package does not cover but stakeholders will immediately ask for: UTM parameter handling, link target/rel attributes, per-locale URLs, and broken-link reporting.

When to Consider This Package

Consider it when:

• You are already running PyroCMS 3.x with the anomaly/navigation module and editors have a documented, recurring need for external or non-page URLs in menus.
• You need a working reference for the Navigation module's link-type contract before writing your own link types (e.g., a product-catalog link type, a deep-link type for a mobile app).
• You are evaluating the extension surface of a CMS you've inherited and want a minimal, MIT-licensed example to read.

Look elsewhere when:

• You are not on PyroCMS/Anomaly. The package has no meaningful value outside that ecosystem, and the Navigation module dependency will not resolve in a standard Laravel application.
• You need this capability to be supported and maintained. Zero stars, zero dependents, and a low opportunity score indicate a demo-grade or reference-grade artifact, not a maintained library — expect no issue triage, no security response, and no compatibility guarantees across PyroCMS majors.
• You require link governance features (validation policy, allowlists, link-checking, analytics instrumentation) — you'll be building those regardless.
• You are on a headless or API-first architecture where navigation is composed in a front-end framework; a CMS-coupled link type is the wrong layer.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed add-on for the PyroCMS Navigation module that lets content editors add external or custom URLs to site menus without engineering involvement. It is not a strategic dependency — no notable adoption, no dependents, no active community — so treat it as a pattern rather than a product. Recommendation: don't budget for it; if external nav links are on the roadmap, plan roughly a day of engineering to implement and own the equivalent internally, with the upside that we control validation, analytics hooks, and future link types.

To engineering: Read it, don't depend on it. It's a minimal implementation of the Navigation module's link-type contract and serves as a template. Vendor the pattern into our codebase, add URL validation/sanitization, target/rel handling, and tests. Flag the abandoned-dependency risk explicitly and keep the extension point documented so future link types (deep links, product links) are cheap.

Risk summary: Low blast radius, low reward. The main risk is passive adoption of an unmaintained package that silently breaks on a PyroCMS upgrade — mitigated entirely by in-housing the roughly equivalent implementation.