Routing Auto Laravel Package

Product Decisions This Supports

Feature feasibility — "automatic, always-correct URLs" for content. This package is a working reference implementation of the capability behind a common roadmap item: URLs that are generated from content (title, slug, parent path) and that update automatically when content is renamed, re-parented, or deleted. If you are scoping a CMS, docs portal, knowledge base, marketplace catalog, or blog, this is evidence the capability is real and enumerable: route schemas, persistence-event listeners, path generators, route providers, and conflict resolution strategies.

Build vs. buy vs. borrow. This is a borrow candidate, not a buy candidate. Archived, 6 stars, 0 dependents, and a last release of 2020-10-28 mean you should not take a runtime dependency. The value is in the design surface: it gives you a checklist for what an in-house solution must handle. That checklist directly feeds an engineering spike estimate.

Requirements specification. It answers concrete questions you will otherwise discover in production: What happens when two objects generate the same path? What happens to inbound links when a slug changes (redirects? 404s? history table?)? Does the route update on create, update, and delete? Does it traverse parent paths? These become acceptance criteria in your ticket, not open questions after launch.

Platform decision — and a correction. Despite the framing of this assessment, this is Symfony CMF, not Laravel. For a Laravel roadmap the honest decision is: do not port a dependency; replicate the pattern. Laravel's idiomatic equivalent is model observers/events plus a sluggable package plus a redirect-history table — a much smaller surface than what CMF ships. For a Symfony roadmap, note that CMF itself is effectively in maintenance mode; the modern equivalents are Symfony's own routing plus a CMS or a headless content service.

Risk register input. License is reported as NOASSERTION, which means automated license scanners could not classify it. That is a legal-review flag, not a formality — it alone can block a supply-chain approval. Combined with archived status and zero dependents, this package should be logged on the "evaluated and rejected" list with reasons, so the same evaluation is not repeated next quarter.

Roadmap sequencing. If automatic routing is on the roadmap, the ordering that follows from this package is: (1) content model with explicit slug fields, (2) route generation on write, (3) permanent redirect history on slug change, (4) conflict resolution policy, (5) bulk/backfill tooling. The last two are where projects actually fail, and they are the two this package spends the most design effort on.

When to Consider This Package

Consider it as a design reference when:

• You are designing automatic URL generation and want a complete enumeration of the edge cases before committing to an architecture.
• You are maintaining a legacy Symfony CMF application that already depends on symfony-cmf/routing and Doctrine, and you need to understand existing behavior. Even here, treat it as frozen code you inherit, not code you adopt.
• You need to justify an in-house build to stakeholders and want prior art to point at.

Consider it as an actual dependency only when all of the following hold:

• The application is already Symfony CMF and already on symfony-cmf/routing.
• The PHP and Symfony versions match the 2020-era constraint set.
• Legal has cleared the NOASSERTION license.
• You accept that there is no upstream support, no security patching, and you are prepared to fork and maintain it internally.

That combination is rare and shrinking. The practical test: if you cannot name the person on your team who will own the fork, do not adopt it.

Look elsewhere when:

• The stack is Laravel, or any non-Symfony PHP framework — the integration points (Doctrine persistence events, CMF routing) do not transfer.
• You are starting a new project. Archived software with a single-maintainer history and zero dependents is a supply-chain liability, and "it still works" is not a support model.
• You need PHP 8.2+ compatibility, security response, or a community to ask questions of.
• The requirement is genuinely just "make a slug from the title." A sluggable package and a unique index is one afternoon; this package is a routing subsystem. Do not buy a framework for a formatting problem.
• You need redirect management, sitemap generation, or localized URLs — those are separate concerns this package explicitly does not own, and pretending otherwise creates scope confusion.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated an open-source component that automatically keeps URLs in sync with content. The capability is real and worth having — broken links after a rename are a measurable SEO and support-cost problem. But the specific package is archived, has no active users we can identify, has not shipped since 2020, and carries an unresolved license classification. Recommendation: do not adopt; use it as a specification for an in-house build. Estimated effort for the in-house version is small and bounded, and it removes the maintenance and legal exposure entirely.

To engineering (the ask): Read it, do not install it. It is a clean, small example of the pattern: listen to persistence events on content objects, derive a path from a configurable schema, resolve collisions, and write or remove the route. Pull three artifacts out of it — the conflict-resolution strategy options, the create/update/delete event coverage, and the separation between path generation and route storage. Then build the same shape against our own stack with our own tests. Budget the redirect-history table from day one; retrofitting it after launch means a crawl of 404s.

To legal and security: Flagging for the record. The repository is archived, the license is not machine-classifiable (NOASSERTION), and there is no maintained release line. This is the reason for rejection, and it is documented here so the evaluation is not reopened.

What "good" looks like if we build it: editing a title changes the URL and issues a 301 from the old one; moving a page rewrites child paths; deleting a page retires its route without orphaning siblings; two pages that would collide are caught at write time, not at request time. That is a two-to-three week story with clear acceptance criteria — which is a far better position than inheriting a frozen dependency and hoping nothing in PHP core changes underneath it.