Simple Statamic Toolbar Laravel Package

Technical Evaluation

Architecture fit — chrisvasey/simple-statamic-toolbar is a Statamic addon rather than a general-purpose Laravel package: it installs through Composer package discovery like any Laravel package, but its lifecycle is bound to Statamic's Control Panel, view layer, and release cadence. It fits Laravel 10/11 apps on Statamic 5 and Laravel 12 apps on Statamic 6, and is not applicable to non-Statamic Laravel applications. Practical consequence: treat it as a Statamic-ecosystem dependency and gate it on Statamic upgrades, not Laravel ones.

Integration feasibility — High. Standard composer require + auto-discovered service provider with publishable config, views, and assets. v1.3.0 removes the hard front-end dependency on Alpine.js and Tailwind CSS, which materially widens the addressable footprint: sites with no Node build step, sites with strict CSP, and classic server-rendered Antlers sites can now adopt it without shipping a second JS framework or utility CSS layer.

Technical risk — Moderate, concentrated in three areas:

• The addon mutates the outgoing response. The "mixed-case closing body tags while preserving embedded script contents" fix confirms it injects markup via string-level HTML manipulation, which is inherently fragile against streaming responses, minifiers, edge workers, and non-standard markup. This is the highest-risk surface in the package.
• "Respect published toolbar template overrides" is a behavioral change, not just a bug fix: overrides that were previously ignored will now take effect, so stale published views can suddenly win and render a broken toolbar after upgrade.
• Preference persistence (expand/collapse across pages) implies a client-side store; cookie-vs-localStorage and consent implications need confirmation.
• Secondary: v1.x, single maintainer, low bus factor; and removal of Tailwind from the toolbar markup is a visual regression surface for anyone who themed against the old class names.

Key questions — Where is the toolbar preference stored (cookie vs localStorage), and is it in scope for consent review? What is the CSP story for the newly external, cache-busted JS asset — does it need a nonce or script-src allowance? How does the toolbar behave behind full-page caching (does injected per-user markup leak onto shared cached pages)? Is rendering permission-gated, or does anonymous traffic get the markup too? What is the minimum Statamic 6 / PHP version? Does the response-rewriting layer have test coverage beyond the newly added CI matrix?

Integration Approach

Stack fit — Statamic 5 or 6 on Laravel 10–12, PHP 8.1+ (confirm exact floor from composer.json). After v1.3.0 no Node toolchain is required, which is the single biggest integration simplification for teams running a static or CDN-fronted asset pipeline.

Migration path from 1.2.x

1. Bump to ^1.3 on a branch; verify the Statamic/Laravel version matrix resolves cleanly.
2. Re-publish assets — the toolbar JS is now a separate, cache-busted asset, so a skipped publish step yields an invisible or unstyled toolbar (a silent failure, not an error).
3. Clear view, config, and response caches, plus any full-page or edge cache, since the injected markup changes.
4. Diff any published toolbar views against the new package views. Because overrides are now honored, pre-existing stale overrides will start winning — decide deliberately to keep, update, or delete each.
5. Grep application CSS for toolbar-specific class names if you previously leaned on the bundled Tailwind.
6. Smoke test: CP links on a subdirectory install, mixed-case body tags, inline <script> near </body>, multisite, and non-editor roles.

Compatibility — No migrations or data model changes; the upgrade is reversible by pinning 1.2.x, so rollback cost is low.

Sequencing — Low-risk change that can ride a normal maintenance window. Sequence it before, not alongside, unrelated front-end or CSP changes so regressions are attributable, and coordinate an edge/CDN purge with the deploy.

Operational Impact

Maintenance — Low ceremony: a Composer bump plus an asset republish. The addition of PHP and JavaScript test runs in GitHub Actions across Statamic 5 and 6 is a meaningful supportability improvement over prior releases and reduces the odds of version-matrix breakage reaching production. Still a single-maintainer community addon — keep a fork/patch contingency in mind.

Support — No vendor SLA and no commercial backing. The blast radius is small: failure is cosmetic or degraded rather than revenue-critical. The exception is if editors rely on the toolbar as their only route into the CP — in that case treat CP link generation (including the subdirectory fix) as a monitored path and confirm it after every Statamic upgrade.

Scaling — Negligible runtime cost: one response-rewrite pass plus a static, cacheable asset. The scaling risk is architectural rather than computational — per-user injected markup interacting with full-page caching and CDNs.

Failure modes

• Asset not published or stale manifest → toolbar absent or unstyled, with no error surfaced.
• Response rewriter meets unusual HTML → malformed page or stripped inline script. The v1.3.0 fix proves this class of bug was live in 1.2.x.
• Stale published view now honored → broken toolbar layout immediately post-upgrade.
• CSP blocks the new external JS → buttons render but are inert; requires a script-src update or nonce.
• Preference storage falls under a consent/privacy review.

Ramp-up — Near zero for a Laravel developer; roughly half a day to run the upgrade checklist end to end. Editors will notice the new accessible expand/collapse controls and persisted preference — brief them ahead of the release so the UI change isn't filed as a bug.