Sitemap Widget Laravel Package

Getting Started

First, the reality check: victoire/sitemap-widget is not a Laravel package. It is a Symfony bundle (Victoire\WidgetSitemapBundle) built for Victoire CMS, a widget-based page builder on top of Symfony 3.x. There is no service provider, no config/sitemap-widget.php to publish, and no Laravel-facing API. If you are building a Laravel app and just need a sitemap, stop here and use spatie/laravel-sitemap. This package only makes sense if you have inherited or are actively running a Victoire site.

Assuming that is the case:

1. Confirm the Composer name in the repo's composer.json before requiring — Victoire bundles are inconsistently named on Packagist (victoire/sitemap-widget vs. victoire/widget-sitemap-bundle). Install with composer require victoire/sitemap-widget.
2. Register the bundle the way your Symfony version expects: AppKernel::registerBundles() on Symfony 3.4, or config/bundles.php if the project has been migrated to 4.x. Victoire 2.x targets Symfony 3.4, so expect the former.
3. Clear cache (bin/console cache:clear) — Victoire caches its widget registry, and a newly installed widget will not appear in the editor until you do.
4. Place it once manually: open any page in the Victoire editor, add the "Sitemap" widget from the widget picker, save, and view the page. That single end-to-end pass tells you more than any doc will.

Where to look first, in order:

• Widget/SitemapWidget.php (or similarly named) — this is the class Victoire instantiates; it defines the widget's name, category, and which Twig template renders it.
• Form/*Type.php — the editor-side configuration form. This is your entire "public API": whatever fields exist here are the only knobs you get.
• Resources/views/*.html.twig — the render template. This is what you will actually override 90% of the time.
• DependencyInjection/ — usually trivial in Victoire widget bundles, but confirms whether any services are registered.

First use case: a footer HTML sitemap listing published pages of the current site, so users (and crawlers following internal links) can reach deep pages. That is the widget's natural job. Do not assume it emits sitemap.xml — check the template before planning around it.

Implementation Patterns

Editor-driven placement. The intended workflow is entirely through Victoire's UI: drag the Sitemap widget into a "footer" business template or a dedicated /plan-du-site page so it applies site-wide rather than per-page. Configure depth/label options via the widget form, not in code.

Template override, not fork. Copy the bundle's Twig file to app/Resources/VictoireWidgetSitemapBundle/views/... (Symfony 3.4) or templates/bundles/VictoireWidgetSitemapBundle/... (4.x) and edit there. Never patch vendor/ — with 2 stars and a 2019 last release, you will be maintaining this yourself and a clean override directory is the only thing that survives a composer update.

Keep the widget thin, push logic into a service. If you need filtering (exclude legal pages, restrict to a locale, limit depth), write a small SitemapLinkProvider service that returns an array of {title, url} and have the template iterate it. Widget classes in Victoire are awkward to unit test; services are not.

HTML sitemap now, XML sitemap separately. If the widget only renders an HTML list, add a real sitemap.xml via a controller action + route that reuses your link provider and renders an XML Twig template. This is the pattern that gets you something Google actually consumes, and it decouples the SEO artifact from the CMS editor state.

Locale handling. Victoire is locale-aware; a page exists per locale. Query pages through Victoire's page repository scoped to $request->getLocale() rather than pulling all pages, or you will emit cross-locale links that 404 or duplicate content.

Cache aggressively. A site-wide sitemap rendered on every request is pure waste. Wrap the widget output in a fragment cache keyed on locale, or set an HTTP cache header on the XML route. Invalidate on page publish/unpublish via a Doctrine listener.

Compose with business entities. If your site uses Victoire BusinessEntities (products, articles), extend the provider to include their routes — this is where a sitemap widget earns its keep versus a static list.

Gotchas and Tips

• Abandoned-adjacent. Last release August 2019, 2 stars, 0 dependents, no tests. Treat the source as the documentation and budget time to read it fully before promising a feature. Assume no upstream fixes.
• Symfony 3.4-era APIs. AppKernel, bundle inheritance, and old Twig bundle-path conventions. On Symfony 5/6 this will not install cleanly; on Symfony 4 you may need to fix deprecations. Check composer.json constraints before adding it to a modern project.
• Do not install it in Laravel "just to try." Composer will pull Symfony components into your dependency graph for zero benefit, and there is no Laravel integration to find.
• Blank widget = missing template, not a broken install. Victoire often renders nothing rather than throwing when a Twig template can't be resolved. Check var/logs/ and confirm the override path matches the bundle name exactly (case-sensitive on Linux).
• Unpublished content leaks. Verify the widget filters on page status. A sitemap that lists drafts is both a UX and a mild information-disclosure problem, and this is a very easy thing to miss on a low-traffic bundle.
• Editor cache. After changing the widget form type or its getName(), run cache:clear and hard-refresh the editor; the widget picker reads a compiled registry.
• Naming collisions. Victoire uses widget names as identifiers. If you clone the widget to customize it, give it a distinct name or the picker will show two identical entries and the wrong one will win.
• Extension points are limited. Realistically you have three: the Twig template override, the widget form type, and replacing the widget's service definition/class via a compiler pass or service alias. There is no event system worth relying on here.
• Pin the version. With no active maintainer, use an explicit version constraint in composer.json rather than ^, and commit composer.lock. A future dependency resolution surprise is the most likely way this bites you.