Routing Bundle Laravel Package

Getting Started

This is a small, unmaintained Symfony bundle (last release October 2016, one star, zero dependents) that wires the Symfony CMF Routing component into a Symfony app. Day-to-day, you are not really "using a bundle" — you are using symfony-cmf/routing (ChainRouter, DynamicRouter, RouteProviderInterface, RouteObjectInterface) with a thin Symfony integration layer for DI/config, and likely a Doctrine-backed route entity/provider.

Minimal steps

composer require tadcka/routing-bundle
composer show tadcka/routing-bundle     # commit/tag + exact constraints
composer why symfony-cmf/routing        # confirm the CMF component pulled in

Read composer.json first — the require block tells you which Symfony majors (almost certainly 2.8/3.x, PHP 5.5+) and which symfony-cmf/routing range you are pinned to. That single file decides whether this is usable on your project at all.

Register the bundle in your kernel/bundles file. The exact class name is in the package's autoload.psr-4:

// app/AppKernel.php
new Tadcka\RoutingBundle\TadckaRoutingBundle(),

Where to look first

1. DependencyInjection/Configuration.php — the authoritative config tree. Anything you read elsewhere about this bundle's options is a guess; this file is not.
2. Resources/config/*.yml — service IDs. You will need these to inject the provider or override it.
3. Entity/ (or Document/) and Provider/ — the route model and its RouteProviderInterface implementation. This is the heart of the package.
4. Controller/ + Resources/views/ — if present, an admin CRUD for routes ships with it. Check Resources/config/routing*.yml for the exposed URLs before enabling anything.

First use case: persist a route row (name + path + defaults such as _controller and _locale), point the CMF chain router at the provider, and resolve an incoming request to that controller. If the bundle ships its provider as a service, this is mostly configuration; if it does not, you implement the provider yourself and this bundle reduces to example code.

Implementation Patterns

Chain router, not the default router. The CMF ChainRouter iterates routers by priority: dynamic (database) routes first, then the stock Symfony router as fallback. Use the chain router explicitly wherever routing matters rather than relying on the global router alias:

$router = $this->get('cmf_routing.router');        // verify service id in Resources/config
$url    = $router->generate($route);              // $route is a RouteObjectInterface
$match  = $router->matchRequest($request);

Changing the global router alias to the chain router is tempting but ripples into every bundle that injects router — do it deliberately, not as a default.

Your route entity must implement RouteObjectInterface (getRouteKey() and getContent()). Generation works by asking the provider for the route by name and then generating from its path; without a stable getRouteKey() you get "route not found" from the generator even though the row exists.

Route provider implementation. A Doctrine repository is the canonical shape:

class RouteProvider implements RouteProviderInterface
{
    public function getRouteCollectionForRequest(Request $request)
    {
        // match on the request path (and host/locale if you support them)
        // return a RouteCollection; set _controller in each Route's defaults
    }

    public function getRouteByName($name, $parameters = []) { /* ... */ }
    public function getRoutesByNames($names) { /* null means "all" */ }
}

getRouteCollectionForRequest() may legitimately return several routes (one per locale); DynamicRouter filters by _locale, so include it in the defaults or you will match the wrong language.

Controller wiring. Set _controller in route defaults to a service-and-method string (AppBundle:Content:show or app.content_controller::show), or let the content be resolved via a ContentRepositoryInterface and dispatched through the CMF content controller (_content_id + content repository). Pick one convention and stay with it — mixing both makes debugging matches miserable.

Admin/CRUD integration. If the bundle exposes edit routes, put them behind your firewall and give editors a cache-clear step (or a listener that invalidates on postUpdate/postRemove). Route edits that don't invalidate the route cache are the single most common "it works locally" bug with this stack.

Gotchas and Tips

• Unmaintained and unpinned. One star, zero dependents, last release 2016. Treat it as a fork candidate: vendor it, or better, depend on symfony-cmf/routing directly and copy only the provider/entity you need. Budget for zero upstream fixes.
• Symfony 4+ will not work as-is. Expect AppKernel-era service definitions, %kernel.root_dir%, @service YAML notation, and no autowiring. On a modern app you are porting, not installing.
• Version resolution is the real risk. Run composer why-not symfony-cmf/routing <version> and composer why-not symfony/framework-bundle <version> before blaming the bundle for an install failure. The CMF routing constraints are tight.
• debug:router will not list your dynamic routes — they live in the database, not in the compiled route collection. Debug by logging $event->getRequest()->attributes->get('_route') in a kernel request listener, or by calling the provider's getRouteByName() from a bin/console command.
• Locale is a default, not a segment. _locale must be present in the route defaults for DynamicRouter to filter correctly; a route with only a path will match every locale and silently win over the localized one.
• Cache invalidation. If a caching decorator wraps your provider, editing a route row does nothing until the cache is cleared. Prefer a decorated provider with explicit invalidation hooks over a blanket cache warmer.
• Extension points: decorate the provider service rather than subclassing, override the service definitions in your app's services.yml, and keep a single RouteProviderInterface implementation so the chain router has exactly one dynamic source. Multiple providers with overlapping paths produce ordering bugs that are hard to trace.
• Escape hatch: if this bundle is only giving you a RouteProvider plus a Doctrine entity, delete it and write those two classes yourself against symfony-cmf/routing. You will keep the useful 200 lines, drop the 2016 Symfony coupling, and gain a maintained dependency.