Menu Bundle Laravel Package

Product Decisions This Supports

• Dynamic Navigation Management: Non-technical stakeholders manage headers, footers, and sidebars through the AdminBundle 3.0 UI, with configurable menus and configurable depth — meaning multi-level nav, per-region menus, and header/footer splits become configuration decisions rather than engineering tickets. This is the single biggest lever for reducing dev dependency on routine navigation changes.
• Multi-Language / Multi-Market Roadmap: Localization is carried forward and now sits on actively maintained Symfony 6.4 / 7.x / 8.x foundations, so menu management can stay aligned with a global roadmap instead of becoming a legacy island.
• Custom Data Sources (now a documented contract): Pluggable item sources are formally documented (doc/sources.md), which lowers the cost of integrating e-commerce catalogs, CMS pages, or external APIs (Shopify collections, HubSpot forms). This supports headless/omnichannel strategy with a known integration cost rather than a research project.
• Build vs. Buy: Still a clear "buy" for navigation management — a pre-built menu editor plus source abstractions avoids building drag-and-drop menu CRUD, ordering, depth constraints, and rendering helpers in-house.
• Platform Coupling Decision (new): v3.0 requires aropixel/admin-bundle ^3.0. Adopting MenuBundle is now also adopting an admin UI platform, with a shared upgrade cadence. That is a strategic dependency worth an explicit call, not a side effect.
• A/B Testing & Personalization: Unchanged foundation — extend item sources or the menu model to show different menus to logged-in vs. guest users, or per campaign.
• Compliance & Accessibility: Configurable depth and structured menus support WCAG-compliant navigation patterns; custom attributes (e.g. newTab) remain available for SEO/accessibility requirements.
• Maintenance-Risk Reversal: The prior assessment flagged a 2022-era release as a risk. v3.0 is a rewrite on current Symfony, which materially improves the vendor-viability signal in a buy decision — but it also means the codebase is young at 3.0 and should be treated as such.

When to Consider This Package

• Avoid if:
  • Your stack is not Symfony/PHP (React/Node.js, Django, static/Next.js sites).
  • You cannot adopt AdminBundle 3.0 — this is now a hard dependency, not optional. If your admin panel is EasyAdmin, Sonata, or a custom SPA, this package is effectively off the table.
  • You need real-time collaborative editing (Google Docs-style menu management).
  • Your menu requirements are extremely simple (static JSON/YAML suffices).
  • You use a headless CMS with built-in navigation (Contentful, Strapi) that already covers menus.
  • Your team lacks Symfony/Doctrine experience for custom sources and entity customization.
• Plan for migration cost if you are on MenuBundle 1.x/2.x: v3.0 is a rewrite with no in-place upgrade path. Treat this as a scoped migration project (read UPGRADE-3.0.md + the installation guide), not a composer update. Budget a spike to size it before committing to a roadmap date.
• Consider alternatives if:
  • You want menu management and admin UI to be independently swappable — this stack now couples them.
  • You need multi-level caching (Redis etc.); this relies on Doctrine caching.
  • Menus require complex dynamic logic (AI-driven recommendations) beyond source pluggability and rendering helpers.
  • You prefer modern Symfony admin alternatives (API Platform Admin, EasyAdmin) and want a single admin surface.
  • You need visual/design-tool preview for menu layouts.

How to Pitch It (Stakeholders)

For Executives:

"This release modernizes our menu management: marketing and content teams self-serve navigation across global sites — drag-and-drop, configurable menu depth, multiple languages — with no dev tickets. Two things changed that matter commercially. First, it now runs on current Symfony (6.4 through 8.x), so the maintenance risk we flagged before is largely resolved. Second, it now sits on our admin platform (AdminBundle 3.0), which means one consistent back-office and one upgrade path — lower long-term TCO, but a tighter vendor relationship. If we already run an older version, this is a rewrite with no in-place upgrade, so it needs to be planned as a migration with its own budget line, not a routine update."

For Engineering:

*"MenuBundle 3.0 is a rewrite on AdminBundle 3.0. Requirements: aropixel/admin-bundle ^3.0, Symfony 6.4/7.x/8.x, Doctrine ORM 2 or 3. No in-place upgrade path — see UPGRADE-3.0.md and doc/installation.md.

• Menu editor lives in the AdminBundle 3.0 UI with configurable menus and configurable depth — configuration replaces a lot of custom rendering logic.
• Pluggable item sources are now a documented contract (doc/sources.md) — integrating products/CMS/APIs is a defined extension point.
• Front-end rendering helpers (doc/front-end.md) reduce bespoke template work.
• Doctrine ORM 3 support means we aren't blocked on a future ORM upgrade. Tradeoffs: (1) coupling to AdminBundle 3.0 — our admin surface and menu tooling now upgrade together; (2) 3.0 is a fresh rewrite, so validate it against our [ProductBundle] source integration and load-test the Doctrine caching layer before rollout; (3) if we're on an older MenuBundle, size the migration as a work item first."*

For Design/Content Teams:

*"You get a dedicated menu editor in the admin panel to:

• Build and rearrange navigation with drag-and-drop — no CSV uploads, no dev tickets.
• Configure separate menus and nesting depth (e.g. a flat footer, a 3-level main nav) without engineering involvement.
• Pull in real content — products, CMS pages, external links — through pluggable sources rather than hand-typed URLs.
• Manage all languages from the same place. Example: restructure the German footer and add a new two-level product menu in minutes, entirely self-service."*