Sitemap Laravel Package

Technical Evaluation

Architecture fit: This is a Statamic sitemap addon for Laravel/PHP applications, not a standalone Laravel package. It fits teams already running Statamic 5 or 6 on PHP 8.2+ and needing generated XML sitemaps with cache management. The v2.0.0 release improves fit for production use through event-based cache invalidation, query-level filtering, cleaner XML output, and a real test/CI matrix.

Integration feasibility: Integration is straightforward for a standard Statamic stack: install via Composer, configure sitemap behavior, and rely on Statamic events for cache invalidation. The main feasibility constraint is platform version: Statamic 3/4 and PHP below 8.2 are no longer supported. Teams on those versions must either stay on the previous addon major line or plan a Statamic/PHP upgrade before adopting v2.0.0.

Technical risk: The release is a major version with breaking changes. Highest-risk areas are custom SitemapEntry usage, custom templates reading priority as a string, and addEntries() callers relying on the old constructor signature or non-null lastmod. The default cache lifetime change from 60 seconds to 1 day is low risk only if event-based invalidation covers the content types that matter to the site. The added tests and CI matrix reduce but do not eliminate integration risk.

Key questions:

• Are we running Statamic 5/6 on PHP 8.2+ in all target environments?
• Do we have custom sitemap templates or code reading SitemapEntry::priority or lastmod?
• Are all relevant content changes covered by entry/term save and delete events?
• Do we need multisite, localized, or non-entry URL coverage that the event invalidation does not address?
• What is our rollback path if XML output or custom templates fail after upgrade?

Integration Approach

Stack fit: Strong fit for current Statamic 5/6 Laravel applications. Weak fit for older Statamic 3/4 applications or PHP 8.0/8.1 environments. The package should be treated as part of the Statamic content-delivery layer, not as an independent Laravel sitemap library.

Migration path: Confirm current Statamic and PHP versions first. If on Statamic 3/4 or PHP below 8.2, either defer v2.0.0 or sequence a platform upgrade before the addon upgrade. If already on Statamic 5/6, upgrade in a branch, run the application test suite, and manually validate sitemap XML. Update any custom templates or callers for priority as float, nullable lastmod, and the revised constructor signature.

Compatibility: v2.0.0 is compatible with Statamic 5 and 6 and PHP 8.2/8.3/8.4 according to the release CI matrix. It is not compatible with Statamic 3/4. Custom code is the main compatibility variable; standard addon usage should be low-risk.

Sequencing:

1. Inventory Statamic/PHP versions and custom sitemap customizations.
2. Upgrade non-production environments first.
3. Run automated tests plus a manual sitemap XML validation.
4. Confirm cache invalidation on entry and term create/update/delete.
5. Validate custom templates and addEntries() integrations.
6. Deploy to production with a clear rollback to the prior addon version if needed.

Operational Impact

Maintenance: Positive. The addition of unit/feature tests and a GitHub Actions PHP/Statamic matrix improves maintainability and gives the TPM more confidence in upgrade validation. The internal cleanup around Generator and shared site-prefix logic is low-impact but signals active maintenance.

Support: Support boundaries are now clearer: Statamic 5/6 and PHP 8.2+. Teams on older versions lose upstream support for this major line. Internal support should document the required platform baseline and the breaking API changes.

Scaling: Improved. Query-level filtering by collection and status reduces unnecessary entry loading, and the longer default cache lifetime lowers regeneration frequency. Event-based invalidation keeps content changes visible without relying on short cache TTLs. This should reduce load on larger content sets.

Failure modes: The main operational failure mode is stale sitemap content if event invalidation does not fire for a given content change. The 1-day cache lifetime means a missed invalidation could persist longer than before, so monitoring and manual cache-clear procedures matter. Other failure modes include template errors from the priority type change, null lastmod handling assumptions, and custom code breakage from the constructor/API changes. The release explicitly fixes a null-lastmod crash and type inconsistencies, which reduces prior runtime risk.

Ramp-up: Low for standard Statamic users; moderate for teams with custom sitemap templates or addEntries() integrations. The TPM should allocate time for platform-version verification, custom-code review, cache-invalidation acceptance testing, and a staged production rollout.