Sitemap Bundle Laravel Package

Getting Started

Start by calibrating expectations: tadcka/sitemap-bundle is a Symfony bundle, not a Laravel package. It has no service provider, no facade, no config file Laravel can publish, and its last release (Feb 2017) predates Laravel 5.5. You will not composer require it into a modern Laravel app and get working code — you'll get platform-constraint failures or a bundle that simply never boots. The realistic "getting started" is treating it as a reference model for a page/sitemap list manager, not as a dependency.

Where to look first in the repo:

• Entity/ — the domain model. Expect a Site-like entity (host/name) and a Page-like entity (path, priority, change frequency, lastmod, possibly a parent/children relation).
• Manager/ (or similar) — the service that assembles the page list and hands it to a renderer. This is the piece worth porting.
• Resources/config/services.yml — shows how the Symfony DI container wires the manager; ignore the plumbing, note the collaborators.
• Resources/views/ — typically a Twig template emitting sitemap.xml; this is your XML contract.
• Tests/ — the best documentation of intended behavior.

Minimal path to first value in Laravel:

1. Clone the repo, composer install in a throwaway PHP 7.x container, run the test suite to see the model in action — do not attempt this inside your Laravel app.
2. Read the entities and write Laravel migrations that mirror them (sites, pages with path, priority, changefreq, lastmod).
3. Write an App\Services\SitemapService that produces the same XML your app needs, using the bundle's template as the output spec.
4. Expose it at GET /sitemap.xml via a route or generate to storage/app/public/sitemap.xml and serve statically.

First use case: a single-site sitemap generated from a pages table — exactly what this bundle models — then extend to multi-site later.

Implementation Patterns

Reference port (recommended). Copy the schema, not the code. Migrate Site/Page to Eloquent models, port manager logic into a testable service, and assert against the bundle's own test expectations. A day's work for a bounded domain.

Sidecar Symfony app. If you truly need the bundle running, deploy a tiny Symfony app that owns the sites/pages tables and serves /sitemap.xml. Laravel writes page data into the same database (read-only from Symfony's side) and links to the sidecar's URL. This keeps the bundle in its native environment and keeps Doctrine out of your Laravel container.

Scheduled generation. A Laravel console command (sitemap:generate) that queries your content models, maps them into page rows, renders XML through a Blade view, and caches the result. Schedule it after content publishes; invalidate the cache on model save via observers.

Multi-site / multi-tenant. The bundle's Site concept maps cleanly onto domain-based routing or tenancy. Keep one page list per site and generate one sitemap per host, plus a sitemap index when you exceed the 50,000-URL / 50 MB per-file limits.

Contracts over concretions. If the bundle exposes interfaces for page providers or URL generation, reimplement equivalents as Laravel contracts (PageProvider, SitemapRenderer) so your service is swappable and unit-testable without a database.

Integration tips. Never share Doctrine entities with Eloquent — mirror tables and use a read-only connection for the Symfony side. Cache generated XML aggressively; sitemaps change far less often than pages. Port the bundle's unit tests to PHPUnit/Pest as your regression suite for the rewritten service.

Gotchas and Tips

• It will not install. PHP 5.5/7.x and Symfony 2.x/3.x constraints will conflict with Laravel 9+ on PHP 8. --ignore-platform-reqs gets you a broken bundle, not a working one.
• No Laravel integration surface. No service provider, no facade, no publishable config. Symfony's sitemap: config key in config.yml has no Laravel analogue; you'd invent config/sitemap.php yourself.
• Doctrine ≠ Eloquent. Entity annotations, lifecycle callbacks, and timestamp handling don't map. Budget rewrite time; don't try to bridge the ORMs.
• Abandoned and unaudited. Last release 2017, 1 star, 0 dependents. No security patches, no PHP 8 compatibility, no community. Treat any code you vendor in as untrusted — audit it, pin it, or fork it.
• XML correctness bites. Absolute URLs only, ISO 8601 lastmod with timezone, changefreq from the fixed enum, priority between 0.0 and 1.0, correct XML escaping in <loc>. Validate output against the sitemaps.org schema before shipping.
• File-size limits. One sitemap holds 50,000 URLs / 50 MB. Plan a sitemap index early if you might grow; retrofitting it is annoying.
• Debugging. If you keep the Symfony sidecar, log at the container boundary — failures there surface as empty sitemaps. If you port, log URL counts and skip reasons (drafts, no-index, missing lastmod) so silent omissions are visible.
• Extension point to preserve. Whatever interface the bundle uses for enumerating pages is the valuable part — replicate it as a contract so content types register their URLs without touching the renderer.
• Recommendation. Given the age and weight (1 star, 0 dependents), use this repo as a design reference for a ~200-line Laravel service, not as a dependency. Building it yourself will be faster, safer, and actually maintainable.