Weave Code
Image Cache Laravel Package
bagisto/image-cache
Bagisto Image Cache is a Laravel package that caches Bagisto storefront images, generating optimized cached versions of product and category images to speed up page loads and reduce repeated image processing. Configure cache storage, image sizes, and cleanup for faster, lighter stores.
Caching extension for the Intervention Image Class
Frequently asked questions about Image Cache
- What does bagisto/image-cache actually do?
- It is a caching extension for the Intervention Image class that stores generated image derivatives instead of reprocessing them on every request. It intercepts transformation closures, hashes the source path plus the transformation parameters into a cache key, writes the resulting image to disk or a cache store, and serves that file on subsequent requests. In practice it speeds up Bagisto storefront pages that render many product and category thumbnails.
- How do I install bagisto/image-cache with Composer?
- Install it with composer require bagisto/image-cache and then confirm how the service provider is registered. Forks of this package frequently keep the upstream Intervention\Image\ImageCacheServiceProvider class name, so Laravel package auto-discovery may or may not fire correctly. Verify the provider fully qualified class name in the source and register it manually in config/app.php if discovery does not pick it up, then publish the config file.
- Does bagisto/image-cache work with Intervention Image v3?
- No. This package depends on ImageManagerStatic and Intervention\Image\Response, both of which were removed in Intervention Image v3. On a v3 stack the package will not install cleanly and cannot be patched with configuration alone; you would need to port it or write the roughly 150-line equivalent yourself. Confirm which Intervention major version every service that renders images is using before you commit.
- Which Laravel and PHP versions does bagisto/image-cache support?
- The package targets the Laravel and PHP era of Intervention Image v2, and its constraints are not actively maintained, so treat composer.json as the only source of truth. Check the require block against your PHP and illuminate/support versions before adding it to a real application. Because there is no upstream issue tracker, you should validate installation and image rendering yourself on your target framework version rather than relying on community reports.
- How do I configure cache storage, image sizes, and cache lifetime?
- Publish the package config file and review every key it exposes, including the delivery route, source and cache paths, size templates, lifetime, and cache driver. Confirm the values are genuinely read from config and not hardcoded in the service provider, since that single detail decides whether rollout is configuration or code surgery. Set the cache driver deliberately: a local disk driver means each node keeps its own cache, while a shared store avoids duplicate work across servers.
- Customers still see an old product photo after I replace the image. Why?
- The cache key is built from the source path plus transformation parameters, so replacing the file at the same path does not change the key and the stale derivative keeps being served until it expires. This is the highest-severity, customer-visible defect in this design. Before go-live you must inject a version token such as the file mtime, an updated_at timestamp, or a content hash into the cache key so a new source produces a new derivative.
- How do I clear cached images or stop the cache from growing forever?
- Look for a cleanup or flush command in the package and pair it with the configured lifetime, then schedule it in Laravel's scheduler so old derivatives are removed on a cadence. The package ships no eviction policy and no locking, so unbounded disk growth and a cold-cache thundering herd on a campaign launch are both yours to handle. Budget storage from your measured derivative count per SKU multiplied by total catalog size, not from an estimate.
- Is bagisto/image-cache safe to expose in production?
- Treat it as internal code you now own: it has zero stars, zero dependents, and no upstream issue tracker, so there is nobody to escalate a bug report to. If the package serves derivatives through a route, the filename comes from the URL, and you must independently verify that the configured paths act as an allow-list and that filenames are normalised to block path traversal and cache poisoning. Also add instrumentation, because an Intervention or Laravel upgrade can silently break static resolution so you get 100 percent cache misses with no error and no alert.
- Is bagisto/image-cache actively maintained?
- Effectively no. It is an internal Bagisto component published as a standalone package, with no community, no dependents, and no public issue tracker, so maintenance is whatever your team does. Accept that trade-off explicitly rather than planning to mitigate it, and cost the escape hatch: the whole dependency is replaceable in roughly half a day by writing your own small decorator. Pin the version and re-test image rendering on every framework upgrade.
- What are the alternatives to bagisto/image-cache?
- If you are on Intervention Image v2 and self-host images, writing roughly 150 lines of your own caching decorator gives you control over key versioning, eviction, locking, and storage. If your stack is on Intervention Image v3, or you would rather not own derivation logic, use a CDN with edge image transformations or a maintained image-resizing service. A managed approach also removes the disk growth and cold-start concerns, at the cost of a network hop and per-transform pricing.
Weaver
How can I help you explore Laravel packages today?