Menu Widget Laravel Package

Product Decisions This Supports

• Build vs. buy for CMS navigation blocks. This package answers a narrow question: "does an off-the-shelf widget exist for placing a menu inside a block-based page editor?" For a Victoire DCMS implementation, yes; for anything else, no. That framing helps you scope whether menu-in-block authoring is a feature you build, buy, or defer.
• Roadmap scoping for content authoring. If your roadmap includes "editors can drop navigation/menu components into pages without developer involvement," this is a reference implementation of that pattern — useful as a spec input even if you never install it.
• Dependency and portfolio hygiene. With 0 stars, 0 dependents, and no release since July 2019, this is a maintenance-liability data point. It supports the decision to exclude it from a dependency allowlist and to flag any transitive usage in an audit.
• Platform standardization. The package being tagged as a "Laravel/PHP package" while actually being a Symfony bundle (WidgetMenuBundle) for Victoire DCMS is a taxonomy error worth correcting in your internal catalog — it affects search relevance and misleads engineers evaluating it for Laravel work.
• Not supported: general menu management, menu rendering, routing-aware menus, or anything a Laravel application would consume. This is a CMS-editor widget, not a menu library.

When to Consider This Package

Adopt only when all of the following hold:

• You are running Victoire DCMS on Symfony (the 2.x-era stack this was built against) and need a menu widget registered in the Victoire widget/block editor.
• You are already maintaining the Victoire dependency set and accept that this package is effectively frozen — you will vendor it or fork it rather than expect upstream fixes.
• The feature is low-stakes and internal-facing; no security or accessibility guarantees are being assumed from it.

Look elsewhere when:

• You are on Laravel. This is not a Laravel package and never was. Use spatie/laravel-menu, lavary/laravel-menu, or a small custom builder plus Blade components.
• You are on modern Symfony. Use knplabs/knp-menu-bundle for the menu model and rendering, and compose it into whatever block/editor layer you actually run (Sylius, Sulu, Ibexa, Craft, or a custom editor). KnpMenu is maintained, widely adopted, and framework-idiomatic.
• You want a menu-in-editor capability generally. Evaluate a headless CMS (Contentful, Storyblok, Sanity) or a maintained block editor (Sulu blocks, Ibexa Page Builder) instead of resurrecting a dormant DCMS bundle.
• You need accessibility, i18n, or caching behavior you can rely on. There is no evidence of ongoing maintenance, so treat every behavior as yours to own.

How to Pitch It (Stakeholders)

Executives: Recommend do not adopt. This is a single-purpose widget plugin for a niche, largely dormant CMS (Victoire DCMS) built on Symfony — not Laravel. It has no stars, no downstream dependents, and no release in over five years. The risk isn't that it will break something; it's the zero value and the distraction of a dead dependency. We should correct its classification in our internal catalog and exclude it from any dependency allowlist.

Engineering: If anyone is genuinely on Victoire DCMS and needs a menu widget in the block editor, this is the only known implementation and should be vendored/forked with an explicit owner. For every other context: on Laravel, use Spatie's menu package or build a thin Blade-component menu; on Symfony, use KnpMenuBundle and integrate at the block layer. Either path gives us maintained code, documented upgrade behavior, and no orphaned dependency. Net: archive the evaluation, standardize on a maintained alternative, and use this package only as a pattern reference for "editable navigation in a page builder."