- Can I use gregwar/image-bundle in a Laravel application?
- Not directly. gregwar/image-bundle is a Symfony 2-era bundle that depends on Symfony's kernel, bundle registration, DI extension and Twig integration, none of which exist in Laravel. In a Laravel project you would install the underlying gregwar/image library and wrap it in your own service provider, facade or job instead of pulling in the bundle.
- How do I install gregwar/image-bundle?
- On a legacy Symfony application you add it with Composer and register the bundle in the kernel, typically also enabling the gregwar_image configuration section. There is no Symfony Flex recipe, so wiring is manual and you must make the cache directory writable by the web user. Expect dependency conflicts on modern PHP 8 and Symfony 5/6/7 projects before you get a clean install.
- Which PHP and Symfony versions does gregwar/image-bundle support?
- The bundle targets the Symfony 2.x and 3.x era and its activity window is roughly 2016 to 2018. PHP 8 and modern Symfony conventions such as autoconfigured services and Flex recipes are effectively untested territory. Run a small smoke-test spike on your exact PHP and framework baseline before committing to it.
- How does gregwar/image-bundle cache generated images?
- Transform parameters are encoded in a URL, and the first request materializes the derived image into a file-based cache directory, usually inside the public web root, so later requests are served statically. That makes the cache path part of your public URL contract and your attack surface. Any cache-busting query string can force regeneration, so plan dimension caps and cache controls.
- Do I need GD or Imagick to use gregwar/image-bundle?
- GD is the expected extension, and Imagick is available upstream through an adapter but adds another compatibility variable. GD will run out of memory on very large images unless you enforce explicit pixel and dimension limits before processing. Confirm the extension is present in every PHP-FPM pool that will serve transforms.
- How do I resize, crop, rotate or watermark an image with it?
- The actual pixel work lives in the gregwar/image library, not the bundle; the bundle exposes it through Symfony services and Twig helpers that generate transform URLs. You configure the cache location in the gregwar_image namespace and let the first hit build the derived asset. In Laravel you would call the library's resize, crop, rotate and watermark methods directly from your own wrapper class.
- Is gregwar/image-bundle safe for user-uploaded images in production?
- Treat it cautiously. Request-triggered generation is a known amplification vector: unbounded dimension parameters and cache-busting URLs can force CPU- and memory-heavy work on every hit. The cache directory is typically web-served and writable, so path handling and permissions are common incident sources. For untrusted uploads, add strict pixel caps, validation and a queue or build-time pipeline rather than on-request generation.
- Does gregwar/image-bundle support WebP or AVIF and responsive images?
- There is no first-class WebP or AVIF negotiation, no responsive srcset pipeline and no CDN signed-URL story. Those capabilities are now table stakes for modern image delivery, so you would be building them yourself or pushing them to an edge service. If format negotiation is on your roadmap, plan for extra work or a different tool.
- What are good alternatives to gregwar/image-bundle for Laravel?
- For server-side manipulation in Laravel, intervention/image, spatie/image and league/glide are the usual choices, and the gregwar/image library itself can be wrapped manually. If you want to avoid request-time generation entirely, consider build-time processing or an edge transform service such as Cloudinary, imgix or Cloudflare Images. That removes the writable-cache and amplification concerns altogether.
- Is gregwar/image-bundle still maintained and should I use it on a new project?
- The repository's activity window is roughly 2016 to 2018, with around 194 stars, no dependents in the scanned set and a weak opportunity score. Assume no upstream fixes and budget for an internal fork if you adopt it. It is only a reasonable fit for an inherited legacy Symfony app on persistent local storage with GD; for greenfield Laravel work, use the underlying library directly or pick a maintained alternative.