Filament Title With Slug Laravel Package

Technical Evaluation

Architecture fit. This is a narrow, additive UI-layer component: one Filament form field that replaces a title + slug TextInput pair. It does not touch persistence, routing, queues, or domain models, and it lives entirely inside the admin panel boundary — meaning it can be removed without data-model surgery. That composition profile is what makes a 0-star package defensible here: the blast radius of it being wrong is one form field, not a subsystem. Fit is contingent on two things we must verify, not assume: (a) the host app runs Filament v3, and (b) the slug is a first-class indexed column on the Eloquent model. If slugs are currently produced in a service layer or model observer, this component creates a second generation authority, and split authority over URL segments is a worse outcome than the duplication it saves.

Integration feasibility. Mechanically trivial: composer require, no service provider or panel plugin registration (it is a form component, not a plugin — confirm this in the README for your version), then swap two inputs for one in the resource schema. The engineering cost is not the integration; it is the surrounding work — deciding uniqueness scope (global vs. per-locale vs. per-parent), backfilling slugs for existing records, and preserving inbound-link equity for any slug that shifts.

Technical risk.

• Unproven vendor posture (adoption signal). Zero stars, single maintainer, minimal install base. This is not a reason to reject — the surface area is small enough to fork in an afternoon — but it sets the governance stance: pin hard, avoid deep coupling, and treat upstream responsiveness as unavailable.
• Release-note opacity (elevated, and specific to this release). 1.0.2's changelog is a compare link and nothing else. Semver classifies it as a patch, so "no breaking changes" is inference, not evidence. For a component that mutates user-visible URL segments, an unreadable diff is not automatically safe — it could be a dependency bump, a bug fix, or a silent change to normalization rules.
• Upstream churn. Filament's major cadence forces plugin compatibility work, and small packages typically lag a major release by weeks to months. That can pin our panel upgrade path.
• Behavioral edge cases. Transliteration and non-Latin titles fail silently by producing an empty or ASCII-mangled slug that still "succeeds." Client-side generation also silently no-ops inside hidden sections, collapsed repeaters, or conditional tabs.

Key questions.

1. What actually changed between 1.0.1 and 1.0.2 — dependency constraint, bug fix, or normalization behavior?
2. Which Filament majors are declared supported, and what is the upper bound in composer.json?
3. How are duplicates handled — auto-suffix, validation error, or silent overwrite? (The README claims "uniqueness handling," but our review suggests that is presentation, with real enforcement left to us.)
4. Does it re-derive the slug when a title is edited after publication, and is that configurable?
5. What is the transliteration behavior for non-Latin and emoji input, and does it compose with spatie/laravel-translatable for per-locale slugs?
6. Does a manual slug edit lock the field against future title changes?

Integration Approach

Stack fit. Laravel 10/11, PHP 8.1+, Livewire, Filament v3. The package belongs in form schemas only — never in controllers, jobs, or API layers. Enforce a single generation authority per resource: either fully inside the component or fully in a model observer.

Migration path. Do not retrofit onto live resources in one pass.

1. Audit every resource with a slug column: uniqueness scope, current generation mechanism, and whether the slug is the route key.
2. Inventory published URLs that would change. Any slug drift requires a 301 redirect/alias map before the component ships.
3. Backfill null and duplicate slugs in a one-off migration; add the unique index if absent.
4. Swap the field on one low-traffic resource, then propagate.

Compatibility. Pin to the exact patch (1.0.2) rather than a caret range while the changelog is uninformative; relax the pin only once we can read a real diff. Read the Filament constraint before scheduling any panel upgrade — if it declares only ^3.0, our v4 planning must carry an explicit dependency-replacement contingency. Test interaction with any localization plugin; dual plugins on the same field commonly collide on validation rules. Also verify disabled/readonly behavior on edit submits the existing slug.

Sequencing and effort.

1. Sandbox spike, lockfile-only: diff-verify 1.0.1 → 1.0.2 against a fixture corpus of titles (Latin, accented, CJK, emoji, very long, duplicate). ~1 dev-day.
2. Staging run against a copy of real content to confirm uniqueness and redirect behavior.
3. Two-week pilot on one internal resource.
4. Resource-by-resource rollout, each behind its redirect map.
5. Revisit the version pin once maintainer release hygiene is established.

Per-resource swap is a few hours of engineering; the backfill and redirect work dominates the schedule and should be estimated and owned separately.

Operational Impact

Maintenance. Low ongoing effort while it works — the component is declarative and small. The recurring cost is version-tracking against Filament majors, which is the most likely trigger for eventual replacement. Budget a standing line item for "evaluate Filament v4 compatibility or fork."

Support. No commercial support; community issues only, with a single maintainer. Escalation for a production-blocking bug is effectively self-service. Mitigation: given the small surface area, forking into our namespace is genuinely cheap — decide at the v4 upgrade point whether to vendor or replace, and do not depend on upstream responsiveness in the meantime.

Scaling. Non-issue. Slug derivation is per-request string work on a single admin form submission; no throughput implications at any realistic content volume. The one scale-adjacent concern is uniqueness validation against a very large content table — index the slug column and validate at the database layer, not just in the form.

Failure modes.

• Silent slug drift on title edit, breaking external links and SEO — highest impact, and it fails quietly. Validate in staging, never first in production.
• Duplicate-slug collisions surfacing as a 500 rather than a form-level validation message when scoping is misconfigured.
• Transliteration collapse for non-Latin titles, producing empty or mangled slugs that still pass.
• Dependency-lock deadlock during a Filament upgrade, blocking the panel instead of degrading gracefully.
• Unreviewed patch upgrade changing normalization across thousands of records with no changelog to consult — precisely the exposure 1.0.2 creates.

Ramp-up. Effectively zero for a developer fluent in Filament form schemas — hours, not days. The real ramp-up burden is institutional, not technical: understanding the existing slug contract and the redirect obligations. Do not assign this to a non-Filament developer. Write the slug-generation policy into each resource's README — when it regenerates, who may manually override, how uniqueness resolves — because that policy, not the API, is what the next maintainer will need.