Menu Bundle Laravel Package

Product Decisions This Supports

• Feature scoping: hardcoded nav vs. CMS-editable nav. The decision this package informs is unchanged — does the client/marketing team need to change navigation without a deploy? If yes, you need a menu entity, a tree/ordering model, and an admin CRUD surface. The package is one legacy implementation of that decision, not the decision itself.
• Build vs. buy for admin CRUD. "Buy" here is still a free micro-bundle with negligible adoption (1 star, 0 dependents) that only just received its first release in roughly a decade. Build is 100–300 lines of migration + entity + admin resource on our own stack. The package's product value remains as a reference spec: it shows the minimum viable data model (menu → items, ordering, labels/links) so we can scope the build rather than adopt the dependency.
• Roadmap sequencing — unchanged and reinforced. Menu management is not a v1 blocker; it lands in v2 when content editors start filing tickets. A patch-level release with no new features is not evidence to pull this forward. Keep it deferred.
• Use cases it maps to: editor-managed primary/footer nav, multi-locale menu labels, permission-gated admin editing. Anything beyond that — personalization, A/B-tested nav, deep accessibility requirements — is out of scope by design, and none of it changed in 2.0.4.

When to Consider This Package

What changed in 2.0.4: a single bugfix — jQuery cookie inclusion for HTTPS applications. No new features, no API changes, no deprecations, no Laravel support, no tests. It corrects an HTTPS-specific defect in the bundle's client-side cookie handling; it does not modernize the stack, and it does not touch the input-sanitization surface. Treat it as a maintenance patch from a nominally alive but effectively unsupported project, not as renewed investment in the package.

Adopt only if all of the following are true:

• You are on a Symfony 2.x/older 3.x app with SonataAdminBundle already installed and in maintenance mode.
• You need nothing more than a menu entity plus a Sonata admin CRUD screen.
• You are willing to vendor/fork it and own the code. A 2.0.4 patch proves someone can cut a release; it does not prove anyone is triaging issues, reviewing security reports, or supporting consumers.

Look elsewhere if:

• You're on Laravel. Still a Symfony bundle — no service provider, no Blade integration, no config publishing. For Laravel, evaluate spatie/laravel-menu or panakour/laravel-menu, or ship a menus/menu_items schema with a Filament/Nova resource.
• You're on modern Symfony (5/6/7) or Sonata 4/5. A 2.x line targeting the 2015-era Sonata admin API will need a rewrite, not an upgrade.
• Security matters. Admin-editable menu labels and URLs remain a stored XSS and open-redirect surface; the 2.0.4 fix is about cookie inclusion over HTTPS, not about validating or escaping editor-supplied content. No test suite to check either.
• You care about front-end stack hygiene. The release confirms the bundle ships its own jQuery-dependent JavaScript for menu state/cookies. Injecting legacy jQuery into a modern Laravel front end (Livewire, Alpine, Vite) is a cost we would not choose to inherit.
• You need caching, i18n, or accessibility guarantees — nested-set/tree performance, per-locale rendering, ARIA-correct markup. None advertised.
• Alternatives are stronger on every axis: sonata-project/menu-bundle and KnpMenuBundle (maintained, ecosystem-backed), or a hand-rolled table if you want zero dependencies.

How to Pitch It (Stakeholders)

To executives: Low license cost, high residual risk — unchanged by this release. The project cut a single patch (2.0.4) to fix HTTPS cookie handling, which shows someone can ship a fix but is not a support commitment: no feature work in about a decade, one star, zero downstream dependents, no one to call when it breaks. Do not put it on a revenue-critical path. If we want editor-managed navigation, the better pitch remains a small internal build (~2–4 engineering days) on our existing stack — we own it, it fits our auth and i18n, and it carries no orphaned dependency or legacy jQuery front end.

To engineering: The new release is a one-line-class bugfix, not a revival. It also confirms the bundle carries jQuery-based client-side code for menu cookies — another reason it does not belong in a Laravel/Vite front end. Treat the repo as a design reference, not a dependency: read the Menu/MenuItem shape, steal the schema, implement natively with our own migrations and admin resource (Filament/Nova) plus validation and escaping on labels and URLs. Note it is still mislabeled as a Laravel package in our tracking; it is a Symfony/Sonata bundle and a non-starter for our Laravel services regardless of patch activity.