Statamic Factory Laravel Package

Getting Started

This release is a maintenance patch: v1.5.1 only bumps the stillat/primitives constraint so the addon resolves cleanly against Statamic 5. There are no new APIs, config keys, or publishable assets to learn — treat onboarding as "confirm the environment, then exercise an existing path."

Minimal steps:

1. Confirm you actually need this version. If you are on Statamic 4, v1.5.1 is not for you; stay on the last 1.4.x tag. The compatibility fix is specifically about the Statamic 5 dependency graph.
2. Check your lockfile first. Run composer why stillat/primitives and composer outdated stillat/primitives. The value of this release depends entirely on whether your app is currently pinned to an older primitives that conflicts with Statamic 5.
3. Update narrowly. composer require <vendor>/<package>:^1.5 --with-dependencies rather than a blanket composer update, so the only moving parts are this addon and stillat/primitives.
4. Clear the right caches. Statamic caches more than Laravel does: php artisan cache:clear, php artisan config:clear, php artisan view:clear, plus php please stache:clear if you touched anything blueprint/collection-adjacent.
5. Smoke-test the first use case. Load the control panel, open a page that uses whatever fieldtypes/modifiers this addon registers, and save it. A primitives mismatch typically surfaces as a fatal in the CP or a silently empty field, not as a Composer error.

Where to look first if something is wrong: composer.lock (which primitives version actually landed), then storage/logs/laravel.log, then the Statamic CP. That order resolves most post-upgrade issues in under five minutes.

Implementation Patterns

Because this is a dependency-only patch, the useful patterns are around version pinning and upgrade hygiene rather than new feature usage.

Pin the pair, not the addon. stillat/primitives and your Statamic major are coupled. Record the working triple (statamic/cms, this addon, stillat/primitives) in your upgrade notes or a docs/ file. When Statamic 6 lands, that triple is what you re-verify, not just one line of composer.json.

composer show statamic/cms stillat/primitives <vendor>/<package>

Treat the addon as the compatibility seam. In multi-site or multi-environment setups, let this package own the primitives constraint and do not require stillat/primitives directly elsewhere. A second direct requirement is the most common cause of "the addon claims Statamic 5 support but Composer still resolves the old primitives."

Stage the upgrade in CI before local. Add a job that runs composer update --prefer-lowest --prefer-stable against the new tag. A dependency-compat patch is exactly the kind of change that passes with your current lockfile and fails on a fresh resolve.

Pair with a regression script. Since there is nothing new to demo, your integration test should assert the addon's existing surface still works: fieldtype renders in the CP, modifier output matches a fixture, any published config still merges. Snapshot the output of one representative template before and after the bump.

Use it to unblock, not to modernize. If you have been sitting on Statamic 5 because this addon wouldn't resolve, v1.5.1 is your green light — but scope that PR to the upgrade itself. Do not bundle unrelated Statamic 5 config migrations into the same change; you will not be able to attribute failures.

Rollout order for production: dev → staging with a real CP login and a content save → production. Statamic's Stache means a bad upgrade can look fine on read and corrupt on write.

Gotchas and Tips

The release note names a transitive dependency — that is the whole change. Do not go looking for a changelog entry describing behaviour. If something breaks after upgrading, the cause is almost certainly the version of stillat/primitives that Composer chose, not this addon's code.

"Fixed compatibility" does not mean "supports every Statamic 5 minor." Verify the addon's own statamic/cms constraint in composer.json rather than assuming ^5.0. Patch releases like this often land with a narrower tested range than the constraint implies.

Silent no-op upgrades are the real risk. If composer update reports nothing changed, you are probably still on a locked primitives that satisfies both constraints by accident. Force the check with composer update stillat/primitives --with-dependencies and read the diff.

Don't skip composer dump-autoload -o. Statamic addons register service providers and often discover fieldtypes/modifiers via classmap or manifest. A stale optimized autoloader after a dependency swap produces "class not found" errors that look like a broken package.

Watch for cache poisoning across environments. If you use Statamic's file-based Stache and deploy by rsync or a shared volume, clear the Stache after the new code lands, not before. A Stache built by the old primitives can persist and cause confusing type errors.

Extension points are unchanged, which is the point. Any subclassing, published config, or view overrides you maintain should carry over untouched. If your overrides reference internals of stillat/primitives, this bump is the moment to confirm those internals didn't shift — check the primitives diff, not this package's.

Debugging a mismatch: composer why-not statamic/cms 5 is more informative than reading the addon's constraints. It tells you which package in the graph is actually blocking the major bump.

Keep the previous tag reachable. Tag your own release before upgrading so a rollback is composer require <vendor>/<package>:1.4.* plus a cache clear, not an archaeology exercise.

Upgrade signal: a patch release that exists solely to chase a Statamic major is a strong hint the maintainer is tracking upstream actively. Check whether v1.5.0 carries feature changes you have not adopted — this patch may be a good moment to read that changelog too.