Statamic Set Header Toggle Laravel Package

Getting Started

eminos/statamic-set-header-toggle is a small Statamic addon that surfaces a Control Panel toggle for the page/set header, so editors can flip that header on or off without editing the blueprint or deleting content. v1.1.0 is a compatibility release: the only change is Statamic 5 support, so the integration surface you already know from v1.0.0 is unchanged.

Minimal steps:

1. composer require eminos/statamic-set-header-toggle:^1.1
2. Confirm the resolved version actually is 1.1.0 — composer show eminos/statamic-set-header-toggle. If you still see 1.0.0, Composer is refusing the new constraint (see Gotchas).
3. Statamic addons are auto-discovered; no manual provider registration is normally required. If the toggle does not appear, run php artisan config:clear && php artisan view:clear and re-check the CP.
4. Publish anything the addon ships (config/views/assets) only if you need to override it: php artisan vendor:publish --provider="Eminos\StatamicSetHeaderToggle\ServiceProvider" (check the README for the exact tag).
5. First use case: open an entry in the CP, toggle the header off, save, and confirm your template output changes. That end-to-end pass is the whole smoke test for this package.

Where to look first when something misbehaves: vendor/eminos/statamic-set-header-toggle/ — the service provider (registration and view/asset hooks), the published config, and the Vue component that renders the toggle. It is a small codebase; reading it is faster than guessing.

Implementation Patterns

Upgrade path for existing Statamic 4 sites. Treat v1.1.0 as a no-op upgrade. Bump the constraint, run composer update eminos/statamic-set-header-toggle, and verify the toggle still renders and persists. No data migration, no field/blueprint changes, no template changes.

Fresh Statamic 5 installs. This is the release that makes the package usable on Statamic 5 at all. Install it alongside your other Statamic 5 addons and check as a group — one addon pinning statamic/cms to ^4.0 will block the whole set, and this package is often the one that gets blamed.

Pin deliberately per environment. If you maintain a Statamic 4 site and a Statamic 5 site in parallel, use ^1.1 in both and let the root statamic/cms constraint disambiguate, rather than hardcoding different addon versions per branch.

CI matrix. If you test the addon (or a site that depends on it), add Statamic 4 and Statamic 5 legs with composer require --prefer-lowest and --prefer-stable so the new constraint range gets exercised in both directions.

Template-side integration. The toggle is only half the feature — the value has to drive rendering. Keep the conditional in one partial (e.g. a header/hero partial) and include it from layouts, rather than sprinkling the same boolean check across templates.

CP-side integration. Pair the toggle with blueprint instructions or a field display name that says what it controls; a toggle labelled only "Header" is ambiguous to editors who do not know the template.

Gotchas and Tips

• This release contains no new features or API changes. Do not go looking for new config keys or methods; anything you read about v1.1.0 that isn't "Statamic 5 support" is wrong.
• Composer silently staying on 1.0.0. Most common failure after this release: the new version exists but your lockfile/constraint keeps you on 1.0.0. Check composer show, and if needed composer why-not eminos/statamic-set-header-toggle 1.1.0 to see which package or platform requirement is blocking it.
• Statamic 5 pulls Laravel 11 / PHP 8.2+. An upgrade that "fails on the addon" is usually a platform requirement failure. Run composer update --with-all-dependencies rather than updating the addon in isolation.
• Cached CP assets. After upgrading, a stale control-panel bundle can make the toggle look broken. Clear config/view caches and hard-refresh; if assets are published, republish them.
• Semver discipline is the useful signal here. v1.0.0 → v1.1.0 is a minor bump, so the maintainer is asserting backwards compatibility for Statamic 4. Still, verify the toggle visually in the CP post-upgrade — this class of addon has no automated test surface you can rely on.
• Extension point is the published view/config, not the PHP. If you need the toggle placed differently, override the published view rather than forking; you'll keep receiving patch releases.
• Low activity risk. A single-line release note is a signal about maintenance cadence: expect occasional compatibility bumps rather than active feature work. That's fine for a UI toggle, but don't build critical editing workflows on it without a fallback (e.g. a plain boolean field in the blueprint you control).