- What does chrisvasey/simple-statamic-toolbar do?
- It is a lightweight Statamic addon that adds an edit button and a link to the Statamic control panel when you are logged in. Editors get quick shortcuts while working in the CMS. It is a Statamic-ecosystem package, not a general-purpose Laravel package.
- How do I install simple-statamic-toolbar with Composer?
- Install it with composer require chrisvasey/simple-statamic-toolbar. The service provider is auto-discovered, and you can publish its config, views, and assets. After upgrading to v1.3.0, make sure you re-publish assets because the toolbar JavaScript is now a separate, cache-busted asset.
- Which Laravel and Statamic versions are supported?
- It fits Laravel 10 and 11 applications running Statamic 5, and Laravel 12 applications running Statamic 6. Confirm the exact PHP floor in composer.json, but the assessment points to PHP 8.1 or newer. It is not applicable to non-Statamic Laravel applications.
- Does this package work in a plain Laravel app without Statamic?
- No. Its lifecycle is bound to Statamic's control panel, view layer, and release cadence, so it only makes sense inside a Statamic installation. Treat it as a Statamic dependency and gate upgrades on Statamic releases rather than Laravel releases alone.
- Do I need Alpine.js or Tailwind CSS to use this toolbar?
- Version 1.3.0 removes the hard front-end dependency on Alpine.js and Tailwind CSS. That means sites with no Node build step, strict CSP setups, and classic server-rendered Antlers sites can adopt it without shipping another JS framework or utility CSS layer. If you previously themed against the bundled Tailwind class names, expect a visual regression surface after upgrading.
- How does the toolbar get added to the page, and does it affect CSP?
- The addon injects markup by mutating the outgoing response, using string-level HTML manipulation near the closing body tag. That approach is inherently fragile against streaming responses, minifiers, edge workers, and non-standard markup, including mixed-case body tags. The new external, cache-busted JS asset may also require a script-src allowance or nonce depending on your Content Security Policy.
- Will the toolbar appear on cached pages or to logged-out visitors?
- The toolbar is intended for logged-in control panel users, but because it mutates the outgoing response, full-page caching needs careful verification. Check that injected per-user markup cannot leak onto shared cached pages and confirm whether rendering is permission-gated or anonymous traffic receives the markup too. Purge full-page and edge caches after installation or upgrade, and smoke test non-editor roles.
- Why did my toolbar break after upgrading to 1.3.0?
- Version 1.3.0 now respects published toolbar template overrides, so stale published views that were previously ignored can suddenly win and render a broken toolbar. The toolbar JS is also a separate cache-busted asset now, so skipping the asset publish step can cause a silent failure. Clear view, config, response, and page caches, diff published views against the new package views, and decide deliberately whether to keep, update, or delete each override.
- Does the toolbar support multisite and subdirectory installs?
- There are no migrations or data model changes, so multisite setups are not affected at the database level. The assessment recommends smoke testing control panel links on a subdirectory install, mixed-case body tags, inline script tags near the closing body, multisite, and non-editor roles. Also coordinate an edge or CDN purge because the injected markup changes.
- Is simple-statamic-toolbar production-ready and well maintained?
- It is a v1.x addon with a single maintainer and a low bus factor, so evaluate that risk against your maintenance requirements. The highest-risk surface is the response-rewriting layer, and you should confirm test coverage beyond the CI version matrix. The upgrade is reversible by pinning 1.2.x, and there are no database migrations, so rollback cost is low.