Nova Slug Field Laravel Package

Product Decisions This Supports

• Admin UX backlog prioritization. This is a two-hour-to-adopt, permanently-removes-a-recurring-annoyance ticket: editors hand-typing slugs for pages, posts, categories, products, events, or docs. As a PM, this is the archetypal "small, boring, high-frequency" item that belongs in a maintenance lane — not a roadmap theme. Frame it as reduced editorial friction, not as a feature.
• Build vs. buy for internal tooling. The alternative is a small custom Nova field (Vue component + PHP field class) that your team owns forever. Buying an MIT field is cheaper only if the requirement stays as narrow as "derive a slug from another field while typing." Any requirement past that — redirects, slug history, per-locale slugs, approval gates — converts this into a build decision, and this package into a dead end.
• SEO / URL governance policy. Human-readable URLs affect search visibility, share previews, and analytics segmentation. Adopting the field forces the product team to write down a convention ("title → slug, lowercase, hyphen-separated, max N chars") instead of letting each editor invent one. That policy document is the real deliverable; the field is just the enforcement surface.
• Editorial workflow rules that need a decision, not code. Auto-generate vs. editor-editable; whether a published slug is ever regenerated when the title changes (it should not be); who may override a slug; and how content created by API, import, seeder, or queue gets a slug when Nova is not in the loop. These are product decisions surfaced by the package, and they must be answered before rollout.
• Scoping signal for a larger content initiative. Its narrowness is diagnostic. If a stakeholder's requirement cannot be met by "generate a slug from another field," you have evidence that the real ask is a content/URL strategy — redirects, slug history, i18n routing — which is a project, not a field. Use the mismatch to reframe the conversation and size the larger effort.
• Roadmap sequencing for localization and IA. Adopt for single-language convenience now, and track multilingual slugs, transliteration rules, and per-locale uniqueness as explicitly separate, unsolved roadmap items. Do not let a field adoption create the false impression that localized URLs are handled.
• Dependency governance precedent. A 140-star, single-maintainer, zero-listed-dependent package with a December 2023 release is a useful test case for how your team classifies dependencies (tactical vs. platform) and what a lightweight risk-acceptance record looks like.

When to Consider This Package

Adopt when all of the following hold:

• The product already runs Laravel Nova, and content is primarily authored by humans in that admin UI.
• The requirement is genuinely basic: derive a slug from a source field, allow manual override, persist it on the model.
• Engineering has confirmed Nova / Laravel / PHP compatibility by reading the installed composer.json constraint, not the README — the last tagged release is December 2023, and Nova 4 vs. 5 differ in asset handling.
• Provenance is verified. The Composer name (benjaminhirsch/nova-slug-field) and the repository (tomhatzer/nova-slug-field) do not match. Confirm the Packagist mapping and the maintainer before shipping it into a production admin.
• The organization accepts a low-activity, community-only, MIT dependency with no SLA and an internal owner named in the dependency register.
• Slug correctness already lives in application code — observer/service with a blank($slug) guard, unique index in the migration, getRouteKeyName() returning slug — so the field is a convenience layer that can be swapped out without touching the data model.

Look elsewhere or build internally when:

• The product is not on Nova, or content is created mainly via API, imports, seeders, or jobs.
• Slugs are business-critical and require redirect management, slug history, translated slugs, transliteration, or approval workflows.
• You need vendor support, an SLA, or broad ecosystem validation.
• Nova compatibility cannot be confirmed — prefer a maintained fork, a vendored copy under nova-components/, or a small custom field.
• The governance cost of adding and tracking another dependency exceeds the cost of owning ~100 lines of custom field code.

Adoption shape: pilot in staging on one low-risk resource behind a per-resource flag, pin the version, document a rollback to a vendored fork or custom field, and roll out resource by resource. Do not bulk-regenerate existing slugs; default to keeping published URLs unchanged.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed add-on for our existing Laravel Nova admin that automatically generates clean, SEO-friendly URLs as editors type, while still letting them override. It removes a small but constant manual step and makes published URLs more consistent across content types — a low-cost quality improvement to a back office we already run. The trade-off is dependency risk: a single-maintainer package, last released in December 2023, with essentially no external adoption evidence. Recommendation: adopt it as a tactical admin convenience only, gated on a compatibility check and a documented fallback to an in-house field. Do not treat it as a platform dependency, and do not let it stand in for a real URL/SEO strategy.

To engineering: Treat the package as presentation-layer sugar inside Nova, never as the source of truth. Concretely: verify the Packagist-to-repo provenance and the Nova/Laravel/PHP constraints, pin the version, pilot on one resource in staging, and keep slug generation, uniqueness, and a database unique constraint in application code (observer + unique index) so API writes, imports, seeders, and queues are covered. Confirm behavior for manual overrides, source-field edits after publish (published slugs must not be silently overwritten), uniqueness across soft-deleted records, and the absence of localized slug support. Roll out resource by resource, avoid bulk regeneration, and keep a documented rollback to a vendored fork or custom field. Include this package in every Nova upgrade plan.

Success metrics and exit criteria (agree before rollout): editor minutes saved per record, reduction in manually corrected or duplicate slugs, consistency of published URL patterns, and zero broken inbound links attributable to slug changes. Exit criteria: a Nova major upgrade breaks the field, upstream maintenance is formally abandoned, or requirements move beyond "generate from a field" — at which point we fork, vendor, or replace, with the data model untouched.