Statamic Image Cropper Laravel Package

Product Decisions This Supports

• Build vs. buy for editorial tooling: Lets you evaluate whether in-control-panel cropping is a differentiator worth engineering time or a commodity capability to adopt off the shelf. If the fieldtype covers your crop workflow, it removes a backlog item; if not, it clarifies exactly what custom work remains.
• Content operations self-service: In-CMS cropping shifts routine image preparation from designers/developers to editors, shortening publish cycles for image-heavy pages (hero banners, news cards, category tiles, social share images).
• Responsive art direction roadmap: Crop coordinates and per-context framing enable multiple aspect ratios from a single source asset — a prerequisite for deciding whether to invest in art-directed responsive images.
• Asset pipeline scope: Helps you decide whether native Statamic assets plus focal-point/Glide transformations are sufficient, or whether you need a richer cropping fieldtype before committing to a DAM or third-party image service.
• Risk acceptance on small dependencies: With ~10 stars and zero dependents, adoption is an explicit bet on a niche MIT package; the decision record should state who owns it, whether you can fork it, and what the fallback is.

When to Consider This Package

• You are already on Statamic (confirm the package supports your Statamic major version — last release was June 2024) and need editors to crop images inside the control panel rather than pre-processing them externally.
• You need stored crop coordinates or context-specific framing beyond what Statamic's built-in focal point provides.
• Your team can absorb the maintenance burden of a low-traffic dependency: expect to read the source, pin the version, and potentially vendor or fork it.
• The feature is additive and non-critical — an optional fieldtype that can be removed without breaking content rendering.

Look elsewhere when:

• You are not on Statamic, or your Statamic version is outside the package's tested range.
• You need vendor support, SLAs, security review guarantees, or an actively maintained dependency with a broad user base.
• An enterprise DAM (Bynder, Cloudinary, imgix, or similar) already owns cropping and transformation; a fieldtype-level cropper would duplicate that.
• Native Statamic assets, focal points, and Glide transformations meet the editorial need — adoption cost outweighs benefit.
• The project is long-lived and high-stakes, where an unmaintained single-maintainer addon is an unacceptable operational risk without a funded fork plan.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT) addon that lets our editors crop images themselves inside the CMS, cutting the hand-off to design for routine image work and speeding up publishing. The cost is near zero and the risk is contained — it is an optional fieldtype we can remove or replace without touching our content model. The trade-off is that it is a niche package with limited community adoption, so we should treat it as something we may need to maintain ourselves rather than a supported product.

To engineering: Single-purpose Statamic fieldtype for in-CP image cropping. Zero dependents and low star count mean limited external validation — review the source, verify compatibility with our Statamic version, pin the release, and confirm the data it stores (crop coordinates/metadata) matches how our templates render images. Budget a small ownership allowance: either we accept maintaining a fork, or we wrap it so it can be swapped for native focal points or a DAM integration later. Do not adopt without a documented fallback path.