Statamic Cp Bar Laravel Package

Technical Evaluation

Basis of assessment. v1.1.0 shipped with no descriptive release notes — only a GitHub compare link (v1.0.0...v1.1.0). The assessment below is therefore derived from package identity, ecosystem conventions, and the shape of the change (a single minor bump on a young addon). Treat all specifics as to be confirmed in a spike, not as verified facts. The absence of notes is itself a finding, logged under Operational Impact.

Architecture fit. 4rn0/statamic-cp-bar is a Statamic addon, not a general-purpose Laravel package. It targets Laravel applications that are Statamic sites; it is inert in a plain Laravel app. Architecturally it sits in the presentation layer — a control-panel UI affordance and/or a front-end overlay for quick CP access — and should be expected to add no domain logic, no persistence layer, and no queue or event surface. That is the good case: low coupling, removable in one composer remove, no data to migrate. The risk case is that the bar renders into front-end responses, which puts it in the path of Blade layouts, response middleware, and HTTP caching. Confirm which of the two it is before scoping anything.

Integration feasibility. High. Statamic addons are Composer-installed and auto-discovered via the addon service provider; worst case requires publishing a config file and clearing caches. Realistic effort is under a day for a developer already fluent in Statamic, including staging verification. No database migrations, no credentials, no external service dependency expected.

Technical risk. Low blast radius, non-trivial tail risk.

• Supply chain / maintenance — single-maintainer, low-star addon. No notes means no visibility into what changed between v1.0.0 and v1.1.0. A minor bump on an unversioned-changelog project can carry behavioural changes.
• Rendering surface — if the bar injects markup into public pages, it interacts with full-page caching, CSP headers, and responsive layouts. A bar leaking onto cached pages served to anonymous users, or visible to roles that should not see it, is the failure we care about.
• Version drift — an addon pinned loosely against Statamic majors is a recurring upgrade tax.
• No functional regression signal — you cannot infer from the notes whether v1.1.0 is additive, a fix, or a quiet behaviour change.

Key questions.

1. What actually changed in v1.1.0? Can the maintainer supply notes, or must we diff the tag ourselves?
2. Does the bar render on the front end, in the Control Panel, or both? Front-end rendering changes the caching and CSP conversation entirely.
3. What are the declared constraints — Statamic major, PHP version, Laravel version? Does v1.1.0 narrow or widen them versus v1.0.0?
4. Is visibility gated by permission/role, or shown to all authenticated users?
5. Is there a config file, and does it need publishing? Any new config keys in v1.1.0?
6. Licence and support model — MIT with community-only support, or anything commercial attached?

Integration Approach

Stack fit. Requires Laravel + Statamic. The Control Panel is Vue-based in Statamic 4/5, so any CP-side UI is delivered as a compiled asset — no build step on our side. Fit is clean for Statamic sites and zero for everything else; if the estate is mixed, this is a per-site decision, not a platform standard.

Migration path. Greenfield install, not a migration. composer require 4rn0/statamic-cp-bar, publish config if prompted, clear Statamic and application caches, verify. Rollback is composer remove plus a cache clear — no schema, no stored data, so rollback is genuinely cheap. That cheapness is the main argument for trialling it.

Compatibility. Two axes to verify, and neither can be resolved from the release notes:

• Addon ↔ Statamic — check composer.json constraints on the v1.1.0 tag against the Statamic major in production.
• Addon ↔ our front-end — if the bar renders publicly, test against the actual layout stack: caching layer, CSP, mobile breakpoints, and any custom CP theming.

Pin the exact version in composer.lock and do not use a floating constraint on an addon with this release hygiene.

Sequencing.

1. Read the composer.json and the compare diff on the v1.1.0 tag (30 minutes; closes the biggest unknown).
2. Feature-branch install against a staging clone of a representative site.
3. Verify CP rendering, front-end rendering, permission gating, and cache behaviour for anonymous vs. authenticated requests.
4. Confirm editor-visible behaviour with one content editor, not just a developer.
5. Merge, lock, deploy. Only after a clean cycle, consider rolling to additional sites.

Operational Impact

Maintenance. This is the dominant cost, and it is governance rather than compute. Solo maintainer, no structured changelog, and a release published with an empty body. Budget an owner who reviews each release manually before bumping, and accept that a floating version constraint is not appropriate here. If the bar becomes genuinely load-bearing for editors, plan for the possibility of forking or vendoring — small, presentation-layer addons are cheap to absorb.

Support. Community/GitHub issues only, no SLA, no vendor escalation path. Assign an internal owner. Escalation for a broken bar is "disable the addon," which is acceptable precisely because the addon does nothing structural.

Scaling. Runtime cost is negligible — a rendered element, no I/O, no queries expected. The scaling question is not load, it is cache topology: if the bar is injected into cacheable responses, it must either be excluded from the cache key or rendered client-side after authentication. Multi-site and multi-language installs need a check that the bar resolves the correct site context rather than defaulting to the primary.

Failure modes.

• Silent behavioural change in a minor release, undetected because there were no notes.
• Cache leakage — bar HTML served from a full-page cache to anonymous visitors.
• Permission leakage — bar visible to roles that should not see it, or offering links that 403 on click.
• CSP breakage — inline styles or scripts blocked by a strict policy, producing a broken or invisible bar.
• Upgrade breakage — addon lags a Statamic major upgrade and blocks the platform upgrade until patched or removed.
• Abandonment — maintainer stops publishing; mitigated by trivial removal.

Ramp-up. Low. A Statamic-fluent developer is productive in under an hour; the editor-facing surface is a bar with links, requiring at most a short note in onboarding docs. Total organisational ramp-up — developer install, editor briefing, runbook entry for "disable the addon if broken" — is roughly half a day.

Recommendation. Proceed to a time-boxed evaluation on one non-critical Statamic site, contingent on step 1 of the sequencing (read the diff and composer.json for v1.1.0). Do not standardise across the estate, and do not adopt a floating version constraint, until the project demonstrates sustained releases with actual release notes. Re-assess on the next release with substantive changelog content.