Sitemap Bundle Laravel Package

Getting Started

Before you write a single line, understand what you are adopting: elcodi/sitemap-bundle is a Symfony bundle from the Elcodi e-commerce suite, not a Laravel package. The GitHub repository you are looking at is a read-only split of the elcodi/elcodi monorepo, frozen at a 2016 release and explicitly marked EOL. There is no ServiceProvider, no config publish stub, and no facade — so "day-to-day" here means either (a) running it inside an old Symfony 2.x/3.x Elcodi app, or (b) reading its source as reference material for building your own sitemap generator in Laravel.

Where to look first:

1. The monorepo (elcodi/elcodi), not this split repo — issues, PRs, and history all live there. The split repo's README is a stub and will not help you.
2. The bundle's DependencyInjection/ and Resources/config/ to learn the service IDs and configuration tree.
3. Whatever service is tagged/registered to build the sitemap (expect a generator/renderer pair, plus entity-side URL resolution from Elcodi's Product, Category, and related components).

Minimal install attempt (expect it to fail on modern stacks):

composer require elcodi/sitemap-bundle

This will almost certainly explode on PHP 8 or modern Symfony due to abandoned transitive dependencies. If you must inspect it, do so in a disposable container pinned to the era (PHP 5.6/7.x, Symfony 2.8), then copy the logic rather than the package.

First real use case: in a Laravel app, you are not installing this. You are reading how Elcodi models URL sources for products/categories, then reproducing that with a spatie/laravel-sitemap-style generator or a hand-rolled artisan sitemap:generate command. Treat the bundle as a design reference for e-commerce sitemap concerns (locale-aware URLs, entity enumeration, caching), not a dependency.

Implementation Patterns

Within its native Symfony/Elcodi world, the pattern is container-driven:

• Service-based generation. The bundle registers a sitemap generator as a container service. You inject it (constructor injection) into a controller or a console command and call a generate-style method, then persist the XML to public/ or stream it as a response.
• Entity URL resolution. Product and category URLs come from Elcodi's own API/component layer. The sitemap generator iterates repositories (usually through Elcodi's *Repository or *Provider interfaces) and asks each entity for its URL. This repository-abstraction is the genuinely reusable idea.
• Config-driven inclusion. Expect a config.yml section under the bundle key controlling which entities/locales are included and where output goes. Check Configuration.php before assuming defaults.
• Command/cron workflow. The realistic production pattern is a console command run on a schedule (nightly), writing a static XML file, with cache warming after product changes.

Translating the pattern to Laravel day-to-day:

// app/Console/Commands/GenerateSitemap.php
public function handle(SitemapBuilder $builder)
{
    $builder->addProducts(Product::where('active', true)->cursor());
    $builder->addCategories(Category::all());
    $builder->writeTo(public_path('sitemap.xml'));
}

• Enumerate with cursor() or chunking — Elcodi's e-commerce entities mean potentially tens of thousands of products, and this is the same scaling concern the original bundle had to solve.
• Emit locale-aware URLs (/en/products/..., /es/products/...) if you mirror Elcodi's multi-locale behavior.
• If you keep Elcodi's service wiring, respect its event/subscriber model: hook sitemap invalidation onto the same domain events (product created/updated/deleted) that Elcodi already dispatches.

Gotchas and Tips

• It is EOL and archived. No security patches, no PHP 8 support, no Symfony 5+/Laravel anything. Do not put this in a production dependency list you intend to maintain.
• The split repo is read-only. PRs are ignored; issues belong on the monorepo. Don't waste time opening tickets against this URL.
• Composer dependency hell is the first wall. Conflicts with modern symfony/*, PSR versions, and PHP constraints are near-certain. If you only want the logic, git clone and read — skip composer require.
• Sitemap protocol limits bite at scale. 50,000 URLs and 50 MB uncompressed per file are hard limits; beyond that you need a sitemap index. Verify whether the bundle emits an index or a single file — historically many bundles only do the latter, which fails quietly on large catalogs.
• Caching and invalidation. The typical failure mode is a stale sitemap after catalog edits. If you reuse the concept, tie regeneration to the same events that mutate products/categories, or run a guaranteed daily rebuild.
• Debugging without the container. Since you can't easily boot it, trace behavior statically through DependencyInjection/Extension.php → service definitions → the generator class. Service IDs, not docs, are the source of truth.
• Extension point if you truly must adapt it: decorate the generator service rather than subclassing, and override entity URL providers to control inclusion. On a modern Laravel codebase, though, forking the ~few hundred lines of generation logic under the MIT license is cleaner than resurrecting the bundle.
• Bottom line for a Laravel team: budget minutes to read, not days to integrate. The reusable asset is the pattern (entity→URL providers, command-driven generation, locale handling), and that is well served by maintained packages such as spatie/laravel-sitemap. This bundle itself is a 2016 artifact best left as reference.