ibelieve/statamic-image-cropper
A Statamic CMS addon for cropping images directly in the control panel. Editors can define crop areas and focal points, while developers render the resulting crops in templates, keeping image handling simple and consistent across a Laravel-powered site.
Architecture fit. Despite landing in a Laravel/PHP package review, this is a Statamic addon, not a framework-agnostic package — it registers a Control Panel fieldtype/asset-editing UI and depends on Statamic's addon service provider, asset pipeline, and CP build tooling. That limits its applicability to Laravel applications already running Statamic. Where that precondition holds, it slots in cleanly with no bespoke architecture required.
Integration feasibility. The practical change is a Composer dependency swap: replace tv2regionerne/statamic-image-cropper (upstream, last at v1.7.0) with the iBelieve fork at ^2.0.0. Feasibility hinges on three unknowns: (1) the fork's Packagist package name and whether it replace/conflict with upstream — if it is a bare VCS fork under the same name, we need a repositories block or a fork-and-mirror strategy; (2) whether the persisted crop metadata (focal point / crop coordinates stored against assets) keeps the same YAML schema — if it changed, existing editor crops silently render uncropped; (3) whether the committed build output is compatible with Statamic 6's CP asset registration.
Technical risk. Medium, concentrated in two areas. First, provenance: this is a single-maintainer fork of a broadcaster-owned project (TV2 Regionerne), and the fork is the only path to Statamic 6. Divergence will only grow, and there is no upstream commitment to absorb these changes. Second, rewrite surface: the v2.0.0 headline is a coordinated jump to Statamic 6 + Vue 3 + TailwindCSS 4 (PR #8). That is a full front-end re-platform of the most complex part of the addon — the interactive cropper — not an incremental patch. The major version bump is correctly signalling this, though it is a platform-compatibility break rather than a documented API break. Mitigating signal: the release adds CI, PHPStan/Larastan with deprecation rules, ESLint, multi-PHP-version analysis, and a build-output freshness check. That is a genuine maturity step for a fork, but it was introduced in the same release as the rewrite, so it has no track record of catching regressions.
Key questions.
replace or coexist with tv2regionerne/statamic-image-cropper?Stack fit. Requires a host on Statamic 6, which in practice means a modern Laravel baseline and PHP 8.2+. Node/npm is only needed if we intend to modify or rebuild CP assets. The Vue 3 requirement is the hard gate: a Statamic 5 host runs Vue 2 in the CP, so the two cannot coexist, and there is no version of this addon that straddles both.
Migration path. Do not attempt in-place at the same time as the Statamic 6 upgrade. Sequence: pin upstream v1.7.0 and freeze cropper behaviour; complete the Statamic 5 → 6 upgrade with the cropper temporarily removed or stubbed; then introduce the fork on a feature branch with an exact constraint (2.0.0, not ^2.0.0, until we have a release or two of history). Snapshot a representative set of assets and their stored crop data before the swap and diff after.
Compatibility. Verify against our actual content model, not just a fresh install — the risk concentrates in existing assets with saved crop coordinates. Also confirm the committed build artifacts match the tagged source (the new CI check exists precisely because this is easy to get wrong) and that no composer.lock conflict arises if any other addon still declares the upstream package.
Sequencing.
Maintenance. The dominant ongoing cost is ownership, not code. We would be depending on a personal fork for a production CP feature. Budget for: Renovate/Dependabot watching the fork, periodic diffing against upstream tv2regionerne to anticipate rebases, and a standing decision to either (a) mirror the fork internally under our own namespace, or (b) accept the dependency with a documented exit — vendoring the fieldtype in-house. Recommend (a) as the default; a one-maintainer fork is a supply-chain single point of failure for an editor-facing tool.
Support. No vendor SLA. Upstream won't support Statamic 6 changes it didn't author; the fork author is a first-time contributor to this codebase per the release notes. Internal runbook should cover: how to disable the fieldtype without data loss, how to fall back to plain asset fields, and who triages CP breakage.
Scaling. Runtime cost is low — cropping is editor-time metadata plus whatever image-derivative pipeline (Glide/Imager/CDN) already exists. Confirm whether crop application happens at render/transform time and whether that interacts with our existing image cache and CDN invalidation. No queue or worker changes expected.
Failure modes.
Ramp-up. Low for a team already fluent in Statamic and Laravel — the addon is small and the new PHPStan/ESLint/CI scaffolding plus CLAUDE.md materially lowers the cost of a first internal contribution, which is the fork's most useful side effect. Budget roughly 1–2 days for the evaluation and data-compatibility verification, plus half a day of editor comms and QA per environment. The front-end re-platform means the first upgrade should be scoped as a small project with a rollback plan, not a routine dependency bump.
How can I help you explore Laravel packages today?