Filament Redirects Laravel Package

Product Decisions This Supports

• Build vs. buy for URL/redirect management. This package covers the full loop a growing Laravel product eventually hand-rolls: canonical path storage, redirect resolution, a 404 log, editor-facing admin panel, bulk creation, and CLI recheck. The v1.0.2 notes show the "boring" parts — path normalization, cache invalidation, transaction boundaries — are being actively hardened, which is exactly the work an in-house implementation underinvests in.
• SEO equity and traffic retention during site changes. Ships redirects, Gone/410 semantics (redirects.gone_status), query-string preservation (redirects.preserve_query), and fragment handling. This supports roadmap items like URL restructures, content retirement, product/category sunsets, and domain or section migrations without a bespoke engineering project each time.
• Internationalization roadmap. The v1.0.2 fix for prefixed-language sources targeting another language (de/aktion on an en row served as /de/aktion, with unprefixed languages reached by full address from the root) is a real product capability: it unblocks opening new locales or re-pointing existing localized URLs without a routing rewrite.
• Editorial self-service vs. engineering tickets. The panel, 404-log "Create redirect" and "Gone" modals, and bulk creation mean content/marketing can resolve broken URLs without a deploy. That shifts ongoing cost from engineering capacity to CMS operations — a staffing and process decision, not just a technical one.
• Content-model integrity. "Entity binding follows the target" (bindings dropped for changed, external, or Gone targets, and no longer spread through compaction) matters if redirects are attached to products/pages: it prevents stale bindings from silently resurrecting after content churn.
• Operational scale of the 404 log. The panel "Recheck" now checks the 2,000 most recently seen rows instead of scanning the entire log per request, while redirects:recheck still walks all of it. That is a decision point on log retention policy and on whether the panel is safe for daily editor use on high-traffic sites.
• Release-engineering confidence for v1.0.x. The fixes cluster around canonicalization round-tripping (display() as exact inverse of normalize(), unchanged()), afterCommit cache flushing, and normalized-length validation (191 chars, raising ValidationException instead of a SQL error). These are silent-data-corruption and stale-cache classes of bug — worth a pinning and regression-test decision, not a blocker.

When to Consider This Package

Consider adoption when most of these hold:

• Laravel/PHP stack, and you want redirects managed in-app with Eloquent-backed records rather than at the edge or in a separate service.
• Churn is real and ongoing: recurring URL changes, content migrations, seasonal campaigns, or a 404 backlog someone is expected to work through.
• Non-technical editors own redirects. The panel and log modals are the value; if only engineers ever touch redirects, a config file or CDN rules may suffice.
• Multilingual routing. The language-prefix behavior is now explicit enough to rely on — but only if you actually run prefixed locales; otherwise you inherit complexity for nothing.
• Redirects are attached to entities (products, pages, categories) and you need bindings to track target changes sensibly.
• You can accept v1.0.x maturity. The volume of correctness fixes in a patch release signals an actively stabilized 1.0 line, not a hardened 3.x. Adopt with version pinning, a test around your trickiest stored sources (paths with whitespace, ?, #, https:/-looking inputs from logs, language-prefixed sources), and a plan to re-verify on each patch.

Look elsewhere when:

• Redirects belong at the edge/CDN (Cloudflare, Fastly, nginx maps) for performance or for redirecting traffic that never reaches PHP — a database lookup per request is the wrong tool at the margin.
• You need regex/pattern-based or very high-cardinality rule sets (tens of thousands of rules with complex conditions); check the resolver's lookup cost against your latency budget before committing.
• You need cross-application or pre-launch redirects on a domain that isn't served by this Laravel app.
• Nobody will own the 404 log. Without an operational owner, the log becomes an expensive table and the "Recheck" tooling is wasted.
• You require a stable, semantically-versioned API surface with a long support window and cannot absorb behavioral refinements to normalization between patch releases.
• Audit/compliance requirements demand immutable redirect history and approvals — verify whether the package records who changed what, and when; the notes don't establish that.

How to Pitch It (Stakeholders)

To executives: We currently treat broken URLs as engineering interrupts. This package turns redirect management into an editorial workflow with a built-in record of what broke and why — protecting search ranking and paid landing pages during site changes, and removing a recurring tax on the engineering team. The v1.0.2 release is a hardening release: no new surface area, but fixes for stale caching after failed saves, mishandled paths containing spaces, ? or #, and cross-language redirects. Those are the failure modes that quietly lose traffic, and they're being closed. Cost is a contained integration plus a documented operating routine for the 404 log; risk is moderate-low, mitigated by pinning the version and testing our real URL shapes before rollout.

To engineering: This replaces the custom middleware, path-normalization, cache-map, and admin CRUD we'd otherwise write and maintain. The 1.0.2 changes to note in review: canonical/display round-tripping is now exact, so stored paths survive the edit form unchanged; cache invalidation moved to afterCommit on model saved/deleted listeners and RedirectRepository, so redirects written inside a host transaction won't leave a permanently stale map; target decoding no longer over-decodes %3F/%23/%25 and leaves query and fragment intact; preserve_query now appends before a #fragment; entity bindings are dropped when a target becomes external or Gone; source length (191) is enforced on the normalized path with a ValidationException rather than a SQL error; bulk creation now requires a single language per batch; and the panel's "Recheck" samples the 2,000 most recent rows while redirects:recheck still covers the full log. Behavioral changes to normalization, binding cleanup, and bulk validation are worth a regression pass on existing data — plan a backfill/verification script for stored old_path values that assumed the old non-inverse display() behavior.

To the operating owner: Expect a weekly rhythm: triage the 404 log, create redirects or mark Gone (410 by default via redirects.gone_status), and run redirects:recheck on a schedule rather than leaning on the panel button for full coverage.