Cms Sitemap Bridge Bundle Laravel Package

Getting Started

First, the honest framing: this is not a Laravel package. presta/cms-sitemap-bridge-bundle is a Symfony 2-era bundle that glues presta/sitemap-bundle to PrestaCMS, a Symfony CMF-based CMS. It was last released in February 2014 and the repository is archived. There is no service provider, no facade, no config file that Laravel can read, and its composer constraints (symfony/* ~2.x, PrestaCMS packages) will not resolve against any modern Laravel application. composer require presta/cms-sitemap-bridge-bundle in a Laravel project is a dead end — expect dependency conflicts before you ever see a class.

Where to look first (if you're evaluating it):

Your first use case in Laravel: don't install it. The bundle's entire job is "enumerate CMS pages → emit <url> entries with loc, lastmod, changefreq, priority." In Laravel that is spatie/laravel-sitemap plus a query over your pages model, or a hand-rolled SitemapController. A working first version is roughly:

Route::get('/sitemap.xml', function () {
    $urls = Page::query()
        ->where('published', true)
        ->where('noindex', false)
        ->get()
        ->map(fn ($p) => [
            'loc'      => url($p->slug),
            'lastmod'  => $p->updated_at->toAtomString(),
        ]);

    return response()
        ->view('sitemap', ['urls' => $urls])
        ->header('Content-Type', 'application/xml');
});

If you genuinely inherited a Symfony 2 / PrestaCMS application and are asked to keep it running, the getting-started path is: enable PrestaCMSSitemapBridgeBundle in AppKernel, ensure PrestaSitemapBundle is installed and its /sitemap.xml route is exposed, then confirm the bridge's provider is registered under the presta_sitemap.dumper/provider tag. That is the only context in which this code does anything.

Implementation Patterns

Since direct reuse is off the table, the useful exercise is translating the bundle's patterns into Laravel idioms. The bundle's design is worth borrowing even though the code isn't.

1. Tagged URL providers → Laravel's container tagging. The bundle registers a provider object and tags it so the sitemap dumper discovers it. A clean Laravel analogue is an interface plus $this->app->tag([...], 'sitemap.providers') and a resolver that iterates the tagged bindings. This keeps "pages," "blog posts," and "products" from turning into one 200-line controller.

interface SitemapProvider {
    /** @return iterable<SitemapEntry> */
    public function entries(): iterable;
}

2. Page enumeration with visibility rules. The bundle only emits pages that PrestaCMS considers routable/published. Mirror that with explicit scopes — published(), notNoindex(), and a locale filter. Anything else leaks draft URLs into search results.

3. Per-locale URL sets. The PrestaCMS bridge inherits the CMS's multilingual routing, so a single page yields one <url> per translation, usually with xhtml:link rel="alternate" hreflang="...". In Laravel this maps to one generator per locale and a shared entry object carrying locale and alternates.

4. lastmod from content timestamps, not request time. The bundle pulls modification dates off the CMS page entity. Do the same: updated_at on the model, never now(). A lastmod that changes on every request is worse than no lastmod — crawlers learn to ignore it.

5. Sitemap index for scale. PrestaSitemapBundle splits into a sitemap index with child files by default. Copy that early: a sitemap.xml index plus sitemap-pages.xml, sitemap-posts.xml. The hard limits are 50,000 URLs and 50 MB uncompressed per file.

Integration tips:

• Generate on a schedule into storage (sitemap:generate command, hourly or on publish events) and serve the static file. Request-time generation is fine at 200 pages and painful at 50,000 — the 2014 bundle dodged this by dumping to a static file in web/. Emulate that instinct.
• Trigger regeneration from model events (saved, deleted) on your page model, dispatched to a queue. This is the equivalent of the Symfony kernel.request-era caching the bundle relied on.
• Keep the sitemap route out of locale-prefixed routing; the sitemap lives at one canonical host and enumerates all locales as alternates.
• Add the sitemap to robots.txt explicitly (Sitemap: https://example.com/sitemap.xml) rather than relying on defaults.

Gotchas and Tips

The blockers, plainly.

• Archived since 2014, 1 star, 0 dependents. No maintenance, no security response, no PHP 8 compatibility. PrestaCMS itself is dormant. Treat this as a source of design inspiration only.
• The dependency tree is the problem, not the code. Even in a Symfony app you'd be pinning Symfony 2.3–2.8 to satisfy it. Modern Laravel (10/11/12) requires Symfony 6/7 components — a hard conflict.
• No configuration to speak of. Unlike most bundles that need tuning, there's almost no config surface here, so there's nothing to port. That also means nothing to misconfigure, which is its only virtue.

If you do end up in a legacy Symfony/PrestaCMS install:

• The single most common failure is the provider service not being tagged, so the sitemap silently generates with zero CMS URLs. Debug by dumping the container (debug:container --tag=...) and confirming the provider appears.
• Caching is aggressive — the sitemap is dumped to a static file. After changing page visibility you must clear the cache and re-dump, or you'll serve stale entries for hours.
• lastmod must be W3C datetime (Y-m-d\TH:i:sP). The pre-2014 code paths sometimes emit a bare date; validate with xmllint --noout sitemap.xml.

Cross-cutting sitemap pitfalls (Laravel or otherwise):

• Only canonical, 200-status URLs. A URL that redirects or 404s in the sitemap is a crawl-budget leak. This is the bug most sitemap integrations ship with.
• Trailing slashes and case. /About/ and /about are two URLs. Decide and enforce with a middleware before generation, not by deduping after.
• priority and changefreq are ignored by Google. They're in the bundle because the protocol includes them; don't spend time tuning them.
• Staging leaks. Guard generation with an environment check, or your staging hostnames end up in a sitemap someone submits.
• Validation loop. xmllint, plus Google Search Console's sitemap report, plus a quick count of <url> entries against Page::count() catches most regressions.

Extension point worth remembering: because the bundle's provider is just a tagged service, adding new URL sources never required forking — you registered another provider. That single idea (composable, tagged URL sources aggregated into one sitemap) is the whole takeaway, and it ports cleanly to Laravel's container. Everything else in this package is historical.