Product Decisions This Supports
- Dynamic, database-backed routing vs. static route files. This bundle sits in the decision space of "should content URLs (slugs, landing pages, per-locale/per-site routes) live in YAML/PHP config or in a database that editors can change without a deploy?" For any CMS-adjacent or multi-site product, that is a real roadmap decision with SEO and marketing-velocity consequences.
- Build vs. buy for the routing layer. It represents the "buy/borrow" option: adopt an existing Symfony CMF-based routing implementation instead of hand-rolling a
RouteProviderInterface and route entity model. The honest finding is that this is a bad buy and a cheap build — a custom route provider on top of Symfony's native Routing component is a few hundred lines and fully owned.
- Multi-site / multi-locale URL architecture. CMF-style routing is one of the few OSS patterns that models "same content, many hosts/locales, one route table." If internationalization or white-label sites are on the roadmap, this is the shape of the problem to design for — but not the library to design it with.
- Platform modernization sequencing. The 2016 last release makes this a concrete data point for "how much of our stack is pinned to Symfony 2.x/3.x era dependencies?" That drives an upgrade-epic priority, not a feature decision.
- Not supported: no meaningful signal for feature prioritization, pricing, or user-facing scope. With 1 star and 0 dependents, there is no adoption evidence to cite in a business case.
When to Consider This Package
Consider it only in a narrow, defensive scenario:
- You are already running a Symfony CMF application on Symfony 2.8/3.x, PHP 5.6/7.0–7.1, and this bundle is already installed. Here it is a known quantity to be documented and contained, not a new adoption.
- You need a read-only reference implementation of how Tadcka glued the CMF Routing component into a Symfony bundle (service wiring, route entity mapping, admin hooks) — useful as a 30-minute read, not a dependency.
- You are doing abandoned-dependency triage and need to classify this repo for a migration backlog.
Look elsewhere — decisively — when any of the following is true:
- Greenfield project, or Symfony 5/6/7, or PHP 8.x. The bundle predates Symfony Flex, autowiring conventions, and PHP 8 type semantics. Expect hard incompatibility, not graceful degradation.
- You need a maintained upstream. Prefer
symfony-cmf/routing and symfony-cmf/routing-bundle (the components this wraps) if CMF routing is genuinely required — or, better, implement a small custom RouteProviderInterface against native Symfony Routing.
- You require security patching, an SLA, or a named maintainer. None exist here; the last release is 2016-10-05, there are zero dependents, and the ecosystem signal (1 star) means no community will catch a regression for you.
- The real need is simpler: localized slugs, redirects, or a page-builder. Symfony's native routing plus a
slug column and a Doctrine listener covers most of it; page-builders are better served by a maintained CMS or a headless CMS.
How to Pitch It (Stakeholders)
To executives (one line): We evaluated an open-source routing add-on for the CMS-style URLs marketing wants; it has been unmaintained since 2016 with effectively no user base, so we recommend against adopting it and propose a small in-house routing layer instead — same capability, no orphaned-dependency risk, and roughly one sprint of work.
To the executive summary:
- Opportunity: enabling editors to create and re-slug content pages without engineering involvement is a genuine marketing-velocity win, and it is a prerequisite for multi-locale and multi-brand site expansion.
- Verdict on this package: Do not adopt. One star, zero dependents, last release October 2016. It is glue code over the Symfony CMF Routing component, which we can use directly or replace with ~1 sprint of custom code.
- Risk if adopted anyway: an unsupported dependency in the request path of every page — the highest-blast-radius place in the stack — with no patch path when PHP or Symfony moves.
- Ask: approve the build option (custom route provider on native Symfony Routing) rather than a "free" OSS shortcut that carries a permanent maintenance tax.
To engineering: treat this repo as documentation of an approach, not a dependency. If CMF semantics (route entities, RouteProviderInterface, content-to-route decoupling) fit our model, evaluate the maintained symfony-cmf/routing package directly and vendor a thin adapter; otherwise implement a minimal provider over native Routing and keep the route table in our own schema so we control migrations, caching, and locale fallback behavior. Either way, we own the upgrade path — which is the point.