Follow-up to #3394.
Context
symfony/ux-cropperjs currently requires intervention/image: ^2.5. The v2 line is legacy (PHP 5.4-era) and triggers the indirect deprecations reported in #3394. As noted there, upgrading isn't a drop-in bump: from Intervention v3+, ImageManager no longer accepts an implicit driver-name string — it requires a DriverInterface — which left an open design question: adopt Intervention's official Symfony integration, or let the bundle expose driver selection itself?
Proposal
Upgrade straight to Intervention Image v4 (^4.0, dropping v2) and let users choose the driver via bundle config:
# config/packages/cropperjs.yaml
cropperjs:
driver: gd # gd (default), imagick or vips
driver_service: ~ # optional: a custom Intervention DriverInterface service (takes precedence)
- The
ImageManager service is built via ImageManager::usingDriver(...).
gd/imagick ship with intervention/image; vips uses the official intervention/image-driver-vips package, listed under composer suggest (it needs libvips + ext-ffi). Selecting vips without that package fails fast with an actionable message.driver_service is an escape hatch for a fully custom / pre-configured DriverInterface.
Why v4 (not v3): a single major to maintain, the vips driver is v4-only, and the bundle already requires PHP >= 8.4 (v4 needs >= 8.3). The Crop API maps cleanly: make() -> decodeBinary(), resize(closure) -> scaleDown(), encode() + getEncoded() -> encodeUsingFileExtension().
Backward compatibility: the bundle's public API is unchanged and gd stays the zero-config default, so existing apps are unaffected.
Reference implementation
A working branch (migration + config + docs + tests parameterized over gd & imagick): https://github.com/deluxetom/ux/tree/cropperjs-intervention-v4
Happy to open a PR if this direction looks good — or to adjust if the official-integration route is preferred instead.
Follow-up to #3394.
Context
symfony/ux-cropperjscurrently requiresintervention/image: ^2.5. The v2 line is legacy (PHP 5.4-era) and triggers the indirect deprecations reported in #3394. As noted there, upgrading isn't a drop-in bump: from Intervention v3+,ImageManagerno longer accepts an implicit driver-name string — it requires aDriverInterface— which left an open design question: adopt Intervention's official Symfony integration, or let the bundle expose driver selection itself?Proposal
Upgrade straight to Intervention Image v4 (
^4.0, dropping v2) and let users choose the driver via bundle config:ImageManagerservice is built viaImageManager::usingDriver(...).gd/imagickship withintervention/image;vipsuses the officialintervention/image-driver-vipspackage, listed under composersuggest(it needs libvips +ext-ffi). Selectingvipswithout that package fails fast with an actionable message.driver_serviceis an escape hatch for a fully custom / pre-configuredDriverInterface.Why v4 (not v3): a single major to maintain, the vips driver is v4-only, and the bundle already requires PHP >= 8.4 (v4 needs >= 8.3). The
CropAPI maps cleanly:make() -> decodeBinary(),resize(closure) -> scaleDown(),encode() + getEncoded() -> encodeUsingFileExtension().Backward compatibility: the bundle's public API is unchanged and
gdstays the zero-config default, so existing apps are unaffected.Reference implementation
A working branch (migration + config + docs + tests parameterized over gd & imagick): https://github.com/deluxetom/ux/tree/cropperjs-intervention-v4
Happy to open a PR if this direction looks good — or to adjust if the official-integration route is preferred instead.