Rewrite Bundle Laravel Package

Product Decisions This Supports

• Canonicalization & SEO hygiene as a product requirement, not a cleanup ticket. The bundle's core job — normalizing paths, enforcing lowercase/trailing-slash conventions, redirecting legacy URLs — maps directly to product-owned decisions about one canonical URL per page. PM decision: define the URL policy (case, slash, locale prefix, query-param handling) as a written spec before any code is merged, because the policy is what marketing, SEO, and analytics will live with for years.
• Replatforming / migration sequencing. If a site move or CMS replacement is on the roadmap, redirect coverage is a launch gate. This package's rule-based rewriting lets you de-risk a migration by decoupling "old URL → new URL" mapping from the new application's routing. PM decision: treat redirect coverage (percentage of legacy URLs with a mapped 301) as a go/no-go KPI for cutover, tracked alongside 404 rate and organic-traffic retention in the 30/60/90 days post-launch.
• Internationalization and microsite architecture. Release notes show explicit investment in language-prefix rewriting (gated to configured translation locales) and microsite-aware parameter handling. That supports a decision to expand into new locales or brand/microsite segments without a per-market code branch. PM decision: if i18n or multi-brand is on the 2–4 quarter horizon, choose the URL scheme now (/en/, subdomain, or ccTLD) because retrofitting it later is a redirect-and-SEO cost, not a config change.
• Build vs. buy — with a caveat that reshapes the answer. In a pure Laravel estate this is not a credible "buy." It is a Symfony bundle, and adopting it means carrying Symfony's DI/config/HttpKernel machinery inside Laravel or standing up a bridge. PM decision: buy the design, build the implementation — a thin Laravel middleware plus a url_rewrites table gives the same product outcome with no architectural tax. Budget this as a small, well-scoped story (rule storage + middleware + 301/302 policy + admin visibility), not a platform project.
• Build-vs-buy sanity check on the "buy" side. Even in a Symfony shop, the external signals argue for a reference implementation posture: 0 stars, 0 dependents, single-vendor authorship (sitepark), and a package score in the low-20s. PM decision: cap the exposure — use it as the spec for behavior and edge cases, not as a load-bearing dependency, unless you're already inside the Atoolo/SitePark ecosystem where its conventions and companion bundles pay off.
• Technical-debt and platform-currency decisions. PHP compatibility is declared through 8.5 and 1.6.0 was a chore-only release (tooling moved into Composer, PHP-CS-Fixer adopted). Translation for planning: URL rewriting will not be the thing that blocks a PHP runtime upgrade. That removes a common "we can't upgrade because of this one legacy package" argument from the platform-refresh business case.
• Where the roadmap money should not go. This is not an experimentation or personalization surface. Rules are config-driven and pattern-based; A/B path testing, user-segment routing, or dynamic per-request URL generation belongs in your application or an edge/CDN layer. PM decision: keep the rewrite layer deliberately dumb and auditable — every rule should be explainable to a marketer in one sentence.
• Observability requirement attached to the decision. Any URL-rewriting capability is only worth what you can measure. Commit to instrumenting redirect hits, 404s, and redirect chains (including circular-redirect detection) as part of the same initiative — otherwise you ship an unmeasurable feature and lose the SEO argument you used to justify it.

When to Consider This Package

Adopt (or, more likely, borrow from) it when:

• You have a legacy URL inventory to preserve — an existing site with years of indexed URLs and no clean mapping to the new structure.
• You need locale-prefix or microsite-aware rewriting and want proven handling of the fiddly parts (e.g., only rewriting language prefixes for actually configured translation locales — a real bug fix in 1.4.0).
• Your stack is Symfony-based (or genuinely hybrid), your team is comfortable with DI/YAML configuration, and you want the routing-transparent behavior rather than hand-rolling a kernel listener.
• You're already in the Atoolo/SitePark orbit, where companion bundles and shared conventions make the integration cost near zero.
• Your team cannot staff a custom rewrite subsystem this quarter and the alternative is shipping with broken legacy URLs.

Look elsewhere (or implement natively) when:

• You're on Laravel without Symfony components. The integration requires kernel wrapping, middleware adapters, and config bridging; you'd spend more effort on the adapter than the feature. Use Laravel middleware plus a rewrite table, or an edge/CDN rule engine.
• The requirement is performance-sensitive at scale. No published benchmarks and no adoption history; a rewrite layer sits on every request, so an unproven one is a latency risk you can't yet quantify.
• Rules are genuinely complex or business-logic-heavy (segmentation, A/B, geo, entitlement-based routing). Pattern-based config will fight you.
• You need vendor assurance — SLAs, a support contract, a published security process, or a broad integrator community. None of that exists here.
• You need configuration outside Symfony's idioms (database-backed rules, marketing-editable rules, an admin UI). You'll be building that layer regardless, which erodes the "buy" case.
• You require a formal dependency-vetting gate. Zero stars and zero dependents will fail most procurement or architecture-review scorecards; plan for either an exception with a fork/exit plan or don't pursue it.

How to Pitch It (Stakeholders)

For executives (outcome and risk framing):

"URL structure is a revenue-adjacent decision: broken or duplicated URLs cost us search ranking, traffic, and paid-spend efficiency. This package shows a proven approach to rule-based URL rewriting — canonical paths, legacy redirects, language-prefixed URLs for new markets, and microsite routing — that we can replicate without a platform project. Recommendation: adopt the pattern, build a small Laravel-native implementation, and hold redirect coverage as a launch gate for the replatform. Cost is a scoped story, not a new system. Two caveats worth knowing: the package itself is Symfony-only and has essentially no external adoption (0 stars, 0 dependents), so we're using it as a blueprint, not a dependency; and the maintenance signals are actually healthy — active releases, MIT license, PHP supported through 8.5 — meaning if we ever did depend on it, a PHP upgrade wouldn't be blocked and we could fork it if the vendor walked away."

For engineering (scope, tradeoffs, decision):

"atoolo/rewrite-bundle is a Symfony bundle for rule-based URL rewriting and cleanup: normalize/sanitize paths before routing, redirect legacy URLs, handle language prefixes, and resolve microsites via a rewrite context. It's clean, actively maintained, PHPStan level 9 with E2E coverage and MIT-licensed — and it's not a drop-in for Laravel. It assumes Symfony's DI, config, and HttpKernel, so pure-Laravel adoption means bridge/middleware adapters, which is more work than the feature is worth.

Recommendation: use its behavior as our spec and implement as (a) a Laravel middleware that runs pre-router, (b) a url_rewrites source (config or DB), and (c) an explicit 301/302 policy. Mirror the edge cases the bundle has already paid for: language-prefix rewriting only for configured locales, same-URL rewriting scoped to links only (not assets/API), and microsite-scoped parameter resolution. Add what it doesn't have: redirect-chain and loop detection, hit/404 telemetry, and a cache layer so rule lookup is O(1) per request.

What we're deliberately not doing: taking a hard dependency on an unproven, single-vendor bundle in a Symfony-in-Laravel arrangement. If the stack ever becomes Symfony-first — or we land in the Atoolo ecosystem — revisit; the integration cost drops to configuration and 1.6.0 is a safe, chore-only upgrade with no API changes.

Decisions we need from product, not engineering: canonical URL policy (case, trailing slash, locale scheme, query-param stripping), 301 vs 302 rules, and who owns the redirect map after launch. Those determine more of the outcome than the library choice does."