Sonata Navigation Bundle Laravel Package

Getting Started

Reality check first. presta/sonata-navigation-bundle is not a Laravel package — it is a Symfony 2.x bundle built to extend SonataAdminBundle's sidebar/navigation (custom actions, role-gated items, translated labels, descriptions). It was last released in January 2014, is archived, has one star and zero dependents. There is no path to composer require-ing this into a Laravel app: it depends on Symfony 2.x components, Twig 1.x, and SonataAdminBundle ~2.x, none of which resolve against a modern Laravel composer.json.

So the "getting started" step for a Laravel developer is a decision:

1. Do not install it on Laravel. Treat it as a reference implementation of an idea — customizable, role-aware, translated admin navigation entries.
2. Look first at the source, specifically the bundle's DI extension (the presta_sonata_navigation config tree) and its Twig template that overrides Sonata's navigation block. That pair is the whole package: config in, menu rendered out.
3. Only use it directly if you are maintaining an existing Symfony 2.x + SonataAdmin ~2.x application. In that case: register the bundle in AppKernel, import its routing (if any), and add a presta_sonata_navigation: block to config.yml defining entries with a label, route, role, and description.
4. Your first Laravel use case should be a config-driven admin sidebar: an entry that links to a named route, is visible only to ROLE_ADMIN (or a Gate ability), carries a __('admin.reports') label, and shows a description as a title tooltip. That is exactly the behaviour this bundle provided for Sonata.

Implementation Patterns

The bundle's day-to-day value is a small set of patterns. Map each to Laravel equivalents:

• Config-defined menu entries. The bundle reads menu items from bundle configuration rather than hardcoding them in a template. In Laravel, mirror this with config/navigation.php returning an array of entries (label, route, ability, description, icon, order). Keep the definition declarative so product owners can add items without touching Blade.
• Role gating. Sonata items were filtered by role strings. In Laravel, resolve visibility at render time with Gate::allows($entry['ability']) (policies are cleaner than raw role string comparison, and you avoid drift between menu visibility and controller authorization).
• Translation with a domain. Each entry's label and description were translation keys. Use __('navigation.reports.label') and __('navigation.reports.description') and keep keys in lang/{locale}/navigation.php so missing translations are obvious.
• Template override / extension point. The bundle worked by overriding Sonata's navigation template. Your equivalent is a Blade component (<x-admin.sidebar :items="$menu" />) plus a view composer or a small NavigationServiceProvider that builds and caches the resolved entry list for the request. Register it as a singleton so the filtering happens once per request, not per item per render.
• Custom actions. Where the bundle let you add actions alongside Sonata's standard ones, Laravel's pattern is a NavigationItem value object with an optional action closure or route array, so an item can be a link, a POST form, or an external URL without special-casing in the template.
• Workflow. Define entries → filter by ability → sort by order → pass to the layout (view composer on layouts.admin) → assert with a feature test that a non-admin sees fewer items. A test like actingAs($user)->get('/admin')->assertDontSee('Reports') is the cheapest guard against menu/authorization drift.
• Integration tip. If you must bridge to a legacy Symfony app, keep the menu definition in one place (a YAML or PHP array) and generate both the Sonata config and the Laravel config from it, rather than maintaining two lists.

Gotchas and Tips

• It is dead software. No security fixes, PHP 8 incompatibilities almost certain, Twig 1.x syntax, Symfony 2 service definitions. Do not put it in a production dependency graph you care about.
• The Laravel/Symfony mismatch is total. There is no adapter, no service provider, no facade. Any "integration" is a rewrite of a ~200-line concept, not a port.
• Silent label failures. The original relied on translation keys; if the translation domain was wrong, the sidebar rendered the raw key with no error. In your Laravel equivalent, add a test or an artisan command that scans config/navigation.php keys against the loaded translator and fails loudly on missing entries.
• Role strings vs. Gates. Sonata used role strings; Laravel users expect can:. Pick one and enforce it consistently, otherwise a hidden menu item can still be reachable by URL.
• Caching. Menu config changes need php artisan config:clear (and route:clear if you reference new route names) before you will see them. Do not cache the resolved menu longer than the request unless you tag and invalidate it.
• Ordering is fragile. Config arrays in PHP preserve order, but merged configs (config:cache) can behave differently with nested arrays — use an explicit order integer rather than relying on array position.
• Debugging the resolved menu. dd($menu) in the view composer, or Log::debug(['menu' => $menu->toArray()]), before the component renders. Most "item missing" bugs are an ability check or a route-name typo, not a rendering issue.
• Extension points to steal. The config tree + template override are the only two worth copying conceptually. Everything else (Sonata-specific routing, admin pool access) is replaced by Laravel's Gate, config, and Blade.
• If you must maintain the fork. Pin PHP ~5.3|~5.4, Symfony ~2.3, and SonataAdmin ~2.2; add at least a smoke test that the container compiles with the navigation config loaded; document that the bundle is archived upstream so nobody files issues against the original.
• For greenfield Laravel admin work, skip this entirely and look at Filament, Backpack, or a hand-rolled config-driven sidebar — all three give you role-aware, translated navigation with active maintenance and tests.