Weave Code
Image Symfony Laravel Package
intervention/image-symfony
Symfony integration for Intervention Image, providing a ready-to-use image manager service for resizing, cropping, and applying filters. Configure drivers and options once, then inject the manager anywhere to handle uploads and thumbnails with clean, expressive code.
Symfony Integration for Intervention Image
Frequently asked questions about Image Symfony
- Is intervention/image-symfony a Laravel package?
- No. It is a Symfony bundle that registers Intervention Image's manager as a service inside Symfony's dependency injection container, and it ships a Symfony DI extension plus a bundle configuration tree. Laravel applications should use intervention/image-laravel instead, or bind the core intervention/image manager directly in a service provider. Treating this package as Laravel-compatible will not work because there is no Laravel service provider or facade.
- How do I install intervention/image-symfony with Composer?
- Run composer require intervention/image-symfony and let Symfony Flex register the bundle, or add it manually to config/bundles.php for older Symfony versions. You also need PHP 8.1 or newer as a baseline and either the GD or Imagick PHP extension available in every runtime that touches images, including web, queue workers, CLI, and CI. After installation, verify the bundle's YAML configuration block is loaded and that the container compiles.
- How do I choose between the GD and Imagick drivers in the bundle config?
- Set the driver option in the bundle configuration, typically config/packages/intervention_image.yaml, and point it at either gd or imagick. Driver selection and related options are resolved through the standard Symfony configuration tree at container compile time, so changing the driver requires a cache clear. Because the driver is fixed by configuration, keep separate config for local development and production if your environments differ in available extensions or Imagick policy.
- How do I inject the ImageManager into a controller or service?
- Because the bundle registers the manager as a service, you can type-hint the manager interface or the concrete Intervention Image manager class in a constructor or controller action and let Symfony autowire it. This works anywhere the container resolves services, including custom services, commands, and message handlers. No manual instantiation or factory call is required, which is the main value the bundle adds over using the core library directly.
- Does intervention/image-symfony 4.x require intervention/image 4.x?
- Yes, the version lines are coupled: bundle 4.x is the line that supports core intervention/image 4.x, and bundle 3.x is the line that supports core 3.x. Mixing them typically fails at container resolution or at the first image encode. Before relying on Composer to protect you, confirm the constraint on the core library is a hard major pin rather than an open range.
- What changed in intervention/image-symfony 4.0.0 and is there a migration guide?
- Version 4.0.0 is described as a compatibility bump: the same bundle, DI extension, and configuration glue retargeted at the new core major, with no new framework-native helpers. The release note is a single sentence with no migration guide, no changed-API list, and no link to the core library's breaking changes. That is not enough to plan an upgrade from, so build your migration plan from your own test suite and treat the core v4 breaking changes as an open question.
- Can I install intervention/image-symfony in a Laravel application instead of intervention/image-laravel?
- You should not. The bundle exists to wire the image manager into Symfony's container and configuration system, and that machinery has no meaning in Laravel's service container. The correct Laravel path is intervention/image-laravel, evaluated on its own release cadence against the core v4 library, or a direct container binding of the core package. If the target stack is Laravel, this package is simply out of scope for the migration.
- How should I test image manipulation code that uses this bundle?
- Run your image tests against a single deterministic driver in CI and assert on observable output such as dimensions, MIME type, and file size rather than exact bytes. Make sure the GD or Imagick extension is installed in the CI image, because a missing extension fails at container or encode time rather than at assertion time. Keep a small set of fixture images covering the formats you actually accept, and add one integration test that resolves the manager from the container to prove the wiring works.
- What are the production risks of GD versus Imagick with this bundle?
- The most likely production incident is divergence between GD and Imagick across environments: color profile handling, EXIF orientation, animated GIF and HEIC support, and memory consumption for large images all differ. Imagick additionally depends on policy.xml, which is often stricter in production than in local development and can silently block formats or resource usage. A core major version bump is exactly when encoder and driver defaults drift, so pin versions and re-verify output after upgrading.
- Is intervention/image-symfony well maintained and what are the alternatives?
- It is a thin wrapper with a single maintainer under the MIT license, so its small adoption numbers understate the real exposure, which sits in the core intervention/image library underneath it. Alternatives include binding the core library directly in your container, using intervention/image-laravel on Laravel, or evaluating LiipImagineBundle, Glide, or Imagine for Symfony projects. If you stay on this bundle, budget per-call-site review for the v3 to v4 upgrade rather than assuming the older v2 to v3 playbook transfers.
Weaver
How can I help you explore Laravel packages today?