Ez Image Crop Laravel Package

Product Decisions This Supports

• Legacy content normalization, not new product surface. The package's own description (in Spanish) scopes it to "mejorar el corte de las imágenes en eZ Publish" — improving image cropping in eZ Publish. That is a maintenance task inside a legacy CMS estate, not a capability that differentiates a product. The English "Laravel package" copy reads as generic boilerplate and should not be trusted until someone reads the source.
• Supports a "fix the back catalogue" decision, not a "build an image pipeline" decision. A reasonable use is a one-off or scheduled batch job that re-crops existing assets during a migration or clean-up: normalize hero images, backfill thumbnails, correct off-centre crops flagged by editorial.
• Build vs. buy: the honest answer is "neither, it's a 40-line script." Cropping by width/height/offset is commodity work. intervention/image, spatie/image, League Glide, or a managed image CDN all cover it with active maintenance. Choosing this package is not a buy decision — with 2 stars and a last release in December 2016, it is effectively an adopt-and-own decision, where we inherit the code the moment we depend on it.
• Roadmap implication: treat as a legacy-tax line item, capped and time-boxed. If it enters at all, it enters as "unblock the migration" with an explicit removal ticket, not as a platform dependency other teams are told to build on. Do not let it appear in a roadmap as an "image cropping capability" — that framing invites reuse and quietly spreads the maintenance cost.
• Decision it explicitly does not support: anything customer-facing and long-lived — responsive/art-directed crops, focal-point selection, AVIF/WebP negotiation, CDN-backed delivery, multi-tenant media. If a roadmap item needs any of those, this package is the wrong starting point regardless of how clean the API looks.

When to Consider This Package

Consider it only when all of the following hold:

• You are actively maintaining an eZ Publish / Ibexa estate and need crop behaviour that matches what the legacy stack already does. This is the one place the package is plausibly purpose-built rather than generic.
• The work is non-critical-path and bounded — a batch migration script, an internal admin tool, a one-off backfill — where a failure is caught before publication and re-run cheaply.
• You have verified by reading the source, not the README, that it (a) actually targets your framework and PHP version, (b) does what the description claims, and (c) does not drag in an abandoned dependency chain via composer why-not.
• You are willing to vendor or fork it and own patches, because nobody else will.
• The alternative genuinely costs more — e.g. rewriting crop parity by hand against an unfamiliar legacy CMS.

Look elsewhere if any of these are true:

• Greenfield or modern Laravel. Use intervention/image, spatie/image, or Glide. They are maintained, tested against current PHP/Laravel, and have real documentation.
• You need support, security patching, or an SLA. A package last released in 2016 has no disclosure channel and no patch cadence. MIT gives you the licence, not the maintenance.
• You need anything beyond a static rectangle crop. Focal point, face detection, responsive breakpoints, format negotiation, CDN delivery — none of this is in scope, and bolting it on means you have rewritten the package with extra steps.
• More than one service would use it. Without a central owner, the estate fragments across a fork and an original with no upgrade path between them.
• The evaluation cannot be completed. If nobody will read the source and confirm compatibility, the correct decision is "no," not "probably fine."

How to Pitch It (Stakeholders)

For executives — one paragraph. This is a tiny, free, MIT-licensed image-cropping utility last updated in 2016, with effectively no community around it (2 GitHub stars). Its stated purpose is fixing image crops inside eZ Publish, our legacy CMS — not building an image platform. The capability itself is a commodity that mature, actively maintained libraries already provide. Recommendation: do not adopt it as a strategic dependency. If a specific legacy migration is blocked on it, allow it as a time-boxed internal tool with a named owner and a removal date, and fund that as migration cost, not as product investment. The licence cost is zero; the ownership cost is not.

For engineering — the ask. Spend half a day: read the source, confirm the PHP/Laravel or eZ Publish version constraints in composer.json, and check for conflicts with our pinned runtime. Then either (a) vendor it into our own namespace and treat it as first-party code we maintain, or (b) replace it — cropping by width, height, and offset is a small, well-understood problem with several healthier libraries already in our dependency graph. Please also resolve the discrepancy between the Spanish eZ Publish description and the English Laravel marketing copy before we record it as a dependency; one of those two descriptions is wrong, and that ambiguity is itself a signal about the package's stewardship.

What to avoid saying. Don't describe this as "lightweight and easy to configure" in any internal write-up. That phrasing comes from the package's own promotional copy, is unverified against the code, and will read to a future maintainer as an endorsement we never actually made.