Menu Widget Laravel Package

Getting Started

• Confirm the framework mismatch first. friendsofvictoire/menu-widget is a Symfony bundle (FriendsOfVictoire/WidgetMenuBundle) for Victoire DCMS, not a Laravel package. It has no Laravel service provider, no config/menu-widget.php, no Blade views, and no php artisan commands. In a Laravel codebase it cannot be installed and used as-is.
• If you are maintaining a legacy Victoire/Symfony app, install it with Composer and register FriendsOfVictoire\WidgetMenuBundle\WidgetMenuBundle in the Symfony kernel (app/AppKernel.php on Symfony 3/4-style apps). Clear the cache afterward.
• Look first at three things in the repository: the widget class, the widget form type, and Resources/views. Those reveal the data model, the editable fields, and the rendering contract. Then check composer.json for Symfony, Victoire, PHP, and Twig version constraints.
• First real use case: add a “Menu” widget to a Victoire page in the CMS UI, bind it to a menu or menu items, configure display options, and render it through the widget rendering pipeline in Twig.
• For a Laravel project, use the bundle as a reference implementation instead. The equivalent first step is to install a maintained Laravel menu package such as spatie/laravel-menu, or define a small Menu / MenuItem model pair with a Blade component and a renderer service.

Implementation Patterns

• Widget registration pattern (Symfony/Victoire). The bundle participates in Victoire’s widget system: a widget class extends the Victoire widget base, a form type defines editable fields, and a Twig template renders output. Registration is handled through Symfony DI tags or Victoire’s compiler passes rather than explicit Laravel-style providers.
• Menu data flow. Expect menu items to be stored as entities or structured arrays, fetched by a repository, and rendered as a tree. In a Symfony app, use the provided repository/service and override the bundle template in app/Resources/... when you need custom markup.
• Laravel translation of the same pattern. Create menus and menu_items migrations with parent_id, order, label, url, and target. Add Eloquent relationships and a MenuRenderer service. Expose the result through a Blade component such as <x-menu :menu="$menu" />.
• Rendering workflow. In Victoire: create the menu, attach the widget to a page, configure depth or level options, preview, then clear caches. In Laravel: resolve the menu in a view composer or controller, render with route() and url() helpers, and cache the rendered tree.
• Caching pattern. Menu trees are read-heavy and change rarely. Cache the resolved tree or rendered HTML with a key that includes menu ID and locale. Invalidate on menu or menu-item save via a model observer/event listener (Laravel) or a Doctrine listener/event subscriber (Symfony).
• Localization and routing. Store labels per locale or use translation keys. Resolve links through the framework’s router instead of hardcoding paths; this is especially important if you port the widget concept to Laravel.
• Extension points. In Symfony, override templates, decorate services, or extend the widget form type. In Laravel, keep the renderer behind an interface and use events such as MenuUpdated so the rendering layer can be replaced without touching the CMS or admin code.

Gotchas and Tips

• No Laravel compatibility. There is no auto-discovery, no publishable config, no Blade templates, and no Laravel-specific integration. Do not attempt to bridge this bundle into Laravel; the dependency footprint and Symfony/Victoire assumptions make it impractical.
• Stale and low-signal package. The last release was 2019-07-04, the repository has zero stars and zero dependents, and the opportunity score is very low. Expect old Symfony and PHP constraints, limited documentation, and little community support. Check composer.json before assuming it will install on a modern stack.
• Victoire is a hard dependency. The widget is meaningless outside Victoire DCMS. If the CMS is not already present, the bundle adds no value.
• Version conflicts are likely. Symfony 3.4/4.x-era bundles often conflict with PHP 8.2+ and current Symfony releases. Use composer why-not and platform config to diagnose; pin versions if you must keep a legacy app running.
• Cache invalidation is the usual bug. Menu edits may not appear until the Symfony cache is cleared. Prefer targeted cache keys or tags over full cache clears, and wire invalidation to save/delete events.
• Template overrides can silently fail. Symfony template resolution depends on bundle naming and override paths. Verify the active template with the Symfony profiler or debug:twig.
• Debugging tools differ by framework. On Symfony, use debug:container, debug:event-dispatcher, and the profiler. On Laravel, use php artisan about, Telescope, and Cache::forget() checks. Do not expect the bundle’s internals to map cleanly onto Laravel’s container or event system.
• Maintenance risk. Treat this as abandoned or near-abandoned. If you depend on it, fork it, audit transitive dependencies, and keep the integration isolated behind your own adapter so it can be replaced with a native menu implementation later.