Sitemap Widget Laravel Package

Technical Evaluation

Package classification is wrong for the stated stack. Despite being catalogued as a "Laravel/PHP package," victoire/sitemap-widget is a Symfony bundle (Victoire\WidgetSitemapBundle) built for the Victoire CMS — a French, widget-based page-builder CMS running on Symfony. It is not installable into a Laravel application and provides no Laravel service provider, facade, config publishing, or Artisan surface. This is the single most important finding in the evaluation and should stop any assumption that it is a drop-in Laravel dependency.

Architecture fit: poor outside Victoire, plausible only inside it. The bundle registers a page-builder widget — an editor-droppable block that renders a sitemap of the site's pages into a Twig template. Its value is entirely derived from the Victoire widget registry, the Victoire page/tree model, and Victoire's rendering pipeline. It has no standalone domain logic worth extracting. Outside a Victoire install, the reusable surface is essentially one Twig template and a small query over a page tree — roughly a day of reimplementation.

Integration feasibility: low. Composer install would pull Victoire core packages; the bundle expects Victoire's bundle registration order, its widget annotation/discovery conventions, and the Victoire admin UI to configure it. There is no documented standalone mode. With 2 stars, 0 dependents, and a last release of 2019-08-09, there is no evidence of an active consumer base to validate any integration path.

Technical risk: high and largely unmitigable.

• Abandonment. No release in ~6 years. Victoire itself has low activity; the ecosystem is effectively dormant.
• Version lock. A 2019 bundle will target Symfony 3.4/4.x-era APIs and PHP 7.x. Any current Symfony (6/7) or PHP 8.2+ runtime will hit deprecated/removed APIs in bundle bootstrapping, widget registration, and Doctrine mapping.
• Supply-chain surface. Old transitive constraints (symfony/*, doctrine/*, twig/twig) will conflict with a modern root composer.json and may pin the whole application to EOL components.
• Zero social proof. 2 stars / 0 dependents means no crowd-sourced bug detection, no Stack Overflow corpus, no forks to inherit maintenance from.
• Ambiguous scope. "Sitemap widget" most likely means an on-page HTML sitemap block, not an XML sitemap.xml generator. If the actual requirement is SEO sitemap generation, this package is the wrong artifact entirely.

Key questions for the requester:

1. Is the target application actually Laravel (bundle unusable) or a legacy Symfony/Victoire install (bundle possibly already present)?
2. Is the requirement an XML sitemap for crawlers or an HTML sitemap page for humans? These have completely different solutions.
3. If Victoire: is the site already on Victoire, and which Symfony/PHP versions is it pinned to?
4. Why is this package under consideration — is it already a transitive dependency of an inherited codebase, or a fresh evaluation?
5. What is the cost of a native ~1-day implementation versus the cost of adopting an unmaintained bundle?

Recommendation: reject for new work. Treat as legacy-context-only. If a Victoire install already depends on it, it is a maintenance liability to be scoped for replacement, not a component to build on.

Integration Approach

Stack fit. For a Laravel codebase: no fit. There is no adapter layer worth writing — a Symfony bundle's widget registration has no meaningful mapping onto Laravel's service container or Blade. Do not attempt a bridge. For a Symfony codebase without Victoire: no fit either, because the widget is meaningless without the Victoire builder. Only a Victoire CMS install is a viable host.

Recommended replacement paths, by actual need:

• XML sitemap for search engines → use a maintained Laravel package (e.g. spatie/laravel-sitemap) or Symfony equivalent (presta/sitemap-bundle, dteoh/sitemap-bundle), or generate from the route table in a scheduled job. ~1–2 days.
• HTML sitemap page → a controller + Blade/Twig view iterating the page model, with published/visibility filtering. ~0.5–1 day. This is almost certainly cheaper than the integration, QA, and upgrade risk of the bundle.

Migration path (if a Victoire install already has it). Inventory first: confirm whether the bundle is declared in composer.json directly or pulled transitively; grep templates for the widget's render block; identify which pages embed the widget. Then replace behind a feature flag: build the equivalent Twig partial against the same page-tree query, swap the widget slot for a static include or a lightweight custom widget, verify output parity, then remove the dependency and run composer why/composer update --dry-run to confirm the transitive constraint set relaxes.

Compatibility checklist before any code is written. Pin and verify: PHP version floor in composer.json, Symfony constraint, Twig constraint, Doctrine ORM/DBAL constraint, and whether the bundle uses annotations vs attributes for widget discovery. Run composer require --dry-run in a branch against the actual root project — a constraint conflict here is a fast, cheap kill signal and should gate the whole evaluation.

Sequencing.

1. Classify the need (XML vs HTML sitemap) — half a day, no code.
2. Resolve the stack question (Laravel vs Symfony/Victoire) — this alone may terminate the evaluation.
3. Dry-run dependency resolution against a real branch.
4. Spike native implementation (1 day) in parallel — in most outcomes this wins on cost and risk.
5. Only if the spike fails and a Victoire host exists, evaluate the bundle in a sandbox install.
6. Decide and document the decision to reject/adopt in the dependency register, with a named owner.

Operational Impact

Maintenance. Effectively unowned upstream. A 2019 release with 2 stars means no expectation of security patches, Symfony compatibility fixes, or PHP 8.x support. Adopting it transfers full maintenance to the adopting team: they inherit a vendored bundle they must fork to keep alive. Budget for a fork-and-own arrangement or plan removal — there is no third option.

Support. No vendor, no commercial backing, no meaningful issue-tracker throughput. Internal engineers will be the only support channel. Onboarding docs are likely thin and in the original author's French-language context (Victoire's ecosystem is French-origin), which adds a small but real ramp cost for English-only teams.

Scaling characteristics. The widget renders a page tree on each render — fine for sites with tens or low hundreds of pages, problematic for large content sets, especially uncached in an admin-preview context. Verify whether the page-tree query is cached and whether it respects publication status, locale, and access restrictions. Multi-site and multi-locale behaviour is unverified and a likely source of bugs.

Failure modes to watch.

• Silent drift: stale Symfony APIs break on any framework upgrade, usually at container-compile time — the whole app fails to boot, not just the widget.
• Dependency pinning: the bundle's old constraints block security upgrades elsewhere in the tree, creating a slow accumulation of unpatched transitive packages. This is the highest-cost failure mode and it is invisible until an audit.
• Content leakage: a sitemap widget that surfaces unpublished, draft, or restricted pages is an information-disclosure risk; explicitly test visibility filtering.
• Render recursion / performance: self-referencing page trees or deep hierarchies can blow up render time or loop.
• Orphaning: if the Victoire ecosystem is decommissioned upstream, the package and its transitive Victoire dependencies become unpatchable in place.

Ramp-up. For a team without Victoire experience: high relative to value. Understanding the widget registry, the page model, and the Twig rendering conventions is days of effort for a component that produces a link list. For a team already on Victoire: low — the widget is a familiar pattern. Ramp cost is entirely a function of existing Victoire fluency, which should be confirmed before any estimate is committed.

Bottom line for the roadmap. Score 0.23 and the evidence behind it are consistent: abandoned, unmaintained, single-ecosystem, zero adoption. Fund a native implementation (likely 1–2 engineering days) rather than an integration, and record the rejection so it is not re-evaluated next quarter.