Statamic Cp Bar Laravel Package

Product Decisions This Supports

• Build vs. buy for admin UX. A control-panel bar add-on is a small, disposable convenience layer — the kind of thing a team should never build in-house. This package lets you buy that decision cheaply instead of spending sprint capacity on a front-end admin shortcut.
• Editor adoption and time-to-value. In-context access to the control panel from the rendered site is a workflow affordance, not a feature. It supports decisions about onboarding cost for content teams and the "can a non-technical editor operate this site?" question.
• Upgrade/roadmap sequencing for Statamic sites. Because it is an add-on rather than core, it sits outside the platform upgrade risk envelope — relevant when sequencing Statamic major-version work.
• Scope triage. It is explicitly not a workflow, permissions, or publishing tool. It supports the decision to keep such requirements in core Statamic or dedicated add-ons rather than stretching this one.
• Note on v1.1.0: the published release notes contain only a compare link (v1.0.0...v1.1.0) with no described features, fixes, deprecations, or breaking changes. A 1.x minor bump on its own signals no intended breaking change under semver, but the substance of the release is undocumented. No product decision should be anchored to this release until the diff is reviewed.

When to Consider This Package

Adopt when most of the following hold:

• You are on Statamic (this is a Statamic add-on, not a general Laravel package) and the site is actively maintained on a supported Statamic major version — verify the constraint in composer.json against your version before committing.
• Your editors regularly move between the front-end site and the control panel, and the round-trip cost is a recurring complaint.
• You want a small, easily removable utility with a narrow surface area, not a dependency you will need to reason about during upgrades.
• You can vendor or pin the version, given the single-maintainer footprint and the thin release documentation.

Look elsewhere when:

• You are on plain Laravel/Livewire/Filament or WordPress — this solves nothing for you.
• The underlying need is editorial workflow, approvals, roles, or publishing governance; that belongs in core Statamic or a dedicated workflow add-on.
• You require documented changelogs, a support contract, or a security-response commitment. This release provides none of those, and bus-factor risk on a solo-maintained add-on is a real adoption cost.
• You need certainty about what changed in v1.1.0 before shipping. Read the commit range first; if the diff touches anything beyond presentation, re-run editor-facing smoke tests.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, low-risk convenience add-on for our Statamic content platform. It shortens the loop for editors working on the live site, which is a retention and onboarding win for the content team rather than an engineering initiative. It carries no infrastructure footprint and can be removed without touching the application. Cost is maintenance attention, not build effort. Caveat to state plainly: the v1.1.0 release ships without documented notes, so I am recommending we pin the current version and only bump after a diff review — the recommendation is unchanged from the prior position.

To engineering: Treat this as a presentation-layer add-on. Narrow surface area, no data model or migration implications, removable in a single composer operation. Before upgrading from v1.0.0 to v1.1.0, review the compare range directly (/compare/v1.0.0...v1.1.0) — there are no release notes to rely on, and semver minor does not guarantee a no-op. Add a smoke check on the CP bar rendering and any registered routes/permissions. Pin the version in composer.json and let the upgrade ride a normal maintenance window rather than a hotfix.