Sitemap Widget Laravel Package

Product Decisions This Supports

• Feature scoping for an HTML sitemap / site index page. This package is a content widget for Victoire DCMS (a Symfony CMS with a visual page builder), not an XML sitemap generator. Reviewing it tells you the reference implementation is thin — iterate site pages, render links. That informs the estimate for building the same capability in-house, which is likely 1–2 engineer-days.
• Build vs. buy. With 0 stars and 0 dependents, "buy" carries adoption cost (vendoring, version pinning, security patching, upgrade work) that exceeds the cost of building a small, owned component. The decision this supports is build, unless you are already running Victoire.
• Framework fit / shortlist exclusion. Despite being a PHP package, this is a Symfony bundle for Victoire, not a Laravel package. If your stack is Laravel, there is no adapter or bridge worth writing — the decision is to exclude it from the shortlist entirely.
• Platform lock-in and exit cost. Adopting it couples you to Victoire's widget/page model and its release cadence. That's a real consideration if Victoire is a candidate CMS rather than an incumbent.
• SEO roadmap hygiene. Distinguish the HTML sitemap (UX, internal linking, discovery) from the XML sitemap (search engine protocol, sitemap.xml, hreflang, lastmod). This package should not be allowed to satisfy an SEO/crawlability requirement — that's a separate, well-supported solution.
• Legacy gap-filling. If Victoire is already the incumbent CMS, this is a low-effort way to close a content-team request ("give editors a sitemap block") without a platform change.

When to Consider This Package

Consider it only if:

• You are already running Victoire DCMS and the FriendsOfVictoire bundle family, and
• You need an in-editor HTML sitemap block that editors can place on a page, and
• You are comfortable vendoring or forking the code and owning its maintenance, and
• It is compatible with your Victoire major version, PHP version, and Symfony version constraints (verify before committing), and the license permits your intended use.

Look elsewhere if:

• Your stack is Laravel (or Symfony without Victoire) — no meaningful fit.
• You need an XML sitemap for crawlers — use a maintained generator (e.g., spatie/laravel-sitemap on Laravel, or the equivalent Symfony bundle) that handles lastmod, hreflang, and sitemap indexing.
• You need dynamic, permission-aware, or multilingual sitemaps, pagination for large sites, or caching — a bespoke component is the better path.
• You require support, SLAs, security response, or active maintenance — zero adoption and zero dependents is a strong signal of low maintenance activity and single-vendor risk.
• You need accessibility, i18n, or design-system integration beyond a default link list.

How to Pitch It (Stakeholders)

For executives: This is a niche, low-adoption widget tied to one CMS (Victoire), with no ecosystem around it. It does not represent a strategic dependency or a build-vs-buy savings — the capability it provides is small enough to own internally. Recommendation: do not adopt; treat it as a reference for scope only. If we are ever on Victoire, we'd vendor the snippet rather than take a dependency.

For engineering: It's a thin Symfony widget that renders a list of site pages inside Victoire's page builder. Replicating it is a small, well-bounded task with no external risk; adding it to our dependency graph introduces an unmaintained dependency we'd have to patch ourselves. Note also that it is frequently confused with an XML sitemap generator — it isn't one, and if SEO crawlability is the underlying ask, we should solve that separately with a maintained package.

Decision requested: Approve building a small internal sitemap component (HTML index now; XML generator via a maintained library if SEO requires it) rather than adopting this package.