Menu Bundle Laravel Package

Product Decisions This Supports

• Navigation and information architecture modeling. A menu bundle is the substrate for how users traverse content. Adopting or borrowing from it forces an explicit decision on whether menus are editorial content (editor-curated, versioned, permissioned) or developer configuration (in code, deployed). That distinction drives CMS roadmap and editorial workflow requirements.
• Build vs. buy for CMS navigation. This package is a reference implementation of hierarchical menu storage and rendering in a Symfony/Doctrine content platform. It gives you a concrete artifact to price against: if the feature set roughly matches your needs, the "build" estimate shrinks to integration and hardening rather than design.
• Platform alignment check. Superdesk Web Publisher is a Symfony application; this is a Symfony bundle distributed via a read-only subtree split. If your product is Laravel, this is not a candidate dependency — the decision it informs is "do we adopt a Symfony-based publishing platform or replicate its menu model in Laravel-native tooling (e.g., nested-set/closure-table packages)."
• Roadmap risk quantification. Zero stars, zero dependents, last release June 2018. As a PM, this is a data point for a sunset/avoid decision, not an adoption decision. It belongs in your dependency-risk register and supports a policy of "no unmaintained third-party bundles in the critical path."
• Editorial UX scoping. Menu management is one of the highest-friction CMS admin surfaces (drag-and-drop reordering, multi-locale menus, per-channel menus, link types). Reviewing an existing bundle's domain model is a cheap way to enumerate the edge cases before committing engineering time.

When to Consider This Package

Consider it only under narrow conditions:

• You are already operating Superdesk Web Publisher or a closely related Symfony/Doctrine stack, and you need the menu domain model to stay consistent with the rest of that platform.
• You want a read-only reference — reading the entity relationships, factory, provider, and renderer to inform your own design. Copying patterns is low-risk; depending on the code is not.
• You are evaluating SWP as a whole (publishing platform procurement) and this bundle is one input to that broader assessment rather than a standalone adoption.
• You need PHP 7.x-era Symfony compatibility and have no requirement for active security patching.

Look elsewhere when:

• You are on Laravel. The bundle targets Symfony's bundle/kernel and Doctrine conventions. Integrating it means fighting the framework; the effort exceeds reimplementation.
• You need maintained code. No release since June 2018 means no PHP 8.x support, no security backports, no Symfony 5/6/7 compatibility. Any modern runtime will likely require forking.
• Menus are core to your product. A single-maintainer, zero-dependent bundle should not sit in a critical path. Alternatives with active stewardship — KnpMenu and its Symfony integration, Sylius's menu tooling, or a first-party implementation — are the safer default.
• You need modern capabilities out of the box: multi-tenant menus, API-first/headless delivery, localization workflows, or accessibility-tested rendering. Assume none of these are present and budget for them.

How to Pitch It (Stakeholders)

To executives: This is a small, unmaintained Symfony bundle from the Superdesk Web Publisher ecosystem — zero stars, zero downstream dependents, no release in over six years. It is not something we should adopt as a dependency. It is useful as a free design reference: reading it lets us scope our navigation/menu feature set quickly and avoid reinventing a domain model. Recommendation: no procurement action, no licensing cost, no integration work; treat it as research input and choose an actively maintained or first-party menu solution for the build.

To engineering: The package is a subtree split of SWP's Menu Bundle, so it inherits the parent project's conventions (Symfony bundles, Doctrine entities, service wiring) and its release cadence — which stopped in 2018. Concretely: it will not run cleanly on current PHP or Symfony without a fork, and nobody is watching CVEs. Use it to review entity structure, menu item typing, and rendering approach, then implement against KnpMenu or in-house. Estimate the read as half a day; estimate any attempt to use it as an open-ended maintenance liability.