Super Structured Data Laravel Package

Getting Started

This package extends Statamic with multisite-aware behavior; v2.2.0 is a compatibility hotfix aimed at installs running more than one site, so treat it as the baseline version for any multisite project.

1. Install with composer require (check the constraint picks up ^2.2), then publish config if the package ships one: php artisan vendor:publish --tag=<package>-config.
2. Clear Statamic's caches after install — php artisan statamic:stache:clear, php artisan cache:clear, php artisan config:clear. Stale Stache indexes are the most common cause of "the hotfix didn't apply" reports.
3. Open the config file first. Look for anything keyed by sites or resolved per-site (URLs, locales, driver/handle mappings). That is where the multisite behavior is configured and where this release changed expectations.
4. First use case: take one existing single-site entry, add a second site in config/statamic/sites.php, and verify the package resolves the correct site context for both. If both sites return identical output, the hotfix is not active (see Gotchas).

If you were on 2.0/2.1 in a multisite install, read the changelog and diff your published config against the new stub before upgrading — hotfix releases in this space frequently assume a refreshed config.

Implementation Patterns

Per-site resolution in content pipelines. The core daily workflow is letting the package resolve the current site rather than hardcoding a handle. Bind site context near the request boundary (middleware or a scoped service) and let downstream code read it, so the same Blade partial, Antlers template, or API transformer works across sites.

Multi-site loops for build/export jobs. When generating sitemaps, feeds, search indexes, or static exports, iterate Site::all() and explicitly set the site for each pass. Do not rely on ambient request state inside queued jobs — a job has no request, and the "current site" defaults can silently collapse everything onto the default site.

Cache keys must include the site handle. Any custom caching you layer on top needs site:handle in the key. The multisite compatibility fix changes how site context is derived, not how your cache keys are built — a key that omits the site will still leak content across sites after upgrading.

Testing pattern. Use Statamic's multisite test helpers to assert behavior per site in a single test class: one test per site against the same fixture, plus one test asserting the two sites return different output. That last assertion is what catches regressions where the package quietly resolves everything to the default site.

Integration with localized routing. If you serve sites on separate domains or subdirectories, confirm route generation and asset/URL helpers run inside the resolved site context. Wrap CLI commands (custom artisan commands that touch content) in an explicit site scope, since there is no request to infer from.

Gotchas and Tips

• Silent default-site fallback is the classic failure mode. When site resolution breaks, output rarely errors — it just returns the default site's content everywhere. Add a smoke test that asserts per-site output differs, and run it after every upgrade.
• Upgrade order matters in multisite. Clear Stache and config caches, deploy code, then re-warm. Rebuilding the Stache before the new code is live can bake in old site mappings.
• Queues and scheduled tasks have no site context. Always set the site explicitly at the top of a job or command; don't inherit from a global that was populated during an HTTP request.
• Config publishing is not automatic on minor bumps. A hotfix may add or rename a config key without touching your published file. Diff the package's config stub against yours after upgrading.
• Check the constraint before blaming the package. Composer will happily keep you on 2.1.x if your composer.json pins ~2.1.0. Confirm the resolved version with composer show before debugging behavior.
• Debugging tip: dump the resolved site handle at the point of failure rather than inspecting rendered output. The handle tells you instantly whether resolution is wrong or the underlying query is wrong — two very different bugs.
• Report repros with site count and site tree. A "works on one site, fails on two" report is actionable; "output is wrong" is not. Include the sites config (redacted) and whether the site is on a separate domain or subdirectory.
• Extension point: if you need per-site customization the package doesn't expose, prefer decorating the resolver/service over forking. Hotfixes like 2.2.0 land quickly, and a fork will strand you.