- Is rmzamora/cache-bundle a Laravel package?
- No. Despite being catalogued alongside Laravel/PHP packages, it is a Symfony bundle (a fork of SonataCacheBundle) built on Symfony's DependencyInjection, HttpKernel, EventDispatcher, and Config components. It exposes services such as sonata.cache.manager and uses the Sonata\CacheBundle namespace. There is no Illuminate dependency, no service provider, and no facade, so it cannot be dropped into a Laravel application as-is.
- How do I install rmzamora/cache-bundle in a Laravel app?
- You effectively cannot in any supported way. The bundle expects a Symfony AppKernel and compiler passes to register its services, so a Laravel service provider would have to boot a Symfony DI container around it. That means pulling in symfony/http-kernel, symfony/dependency-injection, symfony/event-dispatcher, symfony/config, and symfony/options-resolver just to construct a cache manager. The integration cost far exceeds rewriting the small amount of logic you actually need.
- Does rmzamora/cache-bundle work with Laravel 10 or 11?
- No. The package pins Symfony components to historical constraints such as ~2.3|~3.0, while Laravel 10 and 11 require PHP 8.1+ and Symfony 6/7 components. Composer resolution will almost certainly fail before you reach runtime. Even if you forced the install, the bundle's container expectations would not line up with Laravel's bootstrap.
- What features does rmzamora/cache-bundle actually provide?
- It bundles a cache manager service with pluggable adapters for Varnish, ESI, SSI, Symfony, and Noop, plus a CacheElement key abstraction and HTTP-based purge (BAN) invalidation. In practice the reusable ideas are deterministic cache keys and explicit invalidation. Both are small enough to reimplement natively — roughly 200 lines — without dragging in a second framework.
- Is rmzamora/cache-bundle safe to use in production?
- It is high risk. The repository is a personal fork that is archived, has 0 stars and 0 dependents, and its delta from upstream is undocumented. The upstream SonataCacheBundle was itself deprecated and abandoned by the Sonata Project in favor of symfony/http-cache and friendsofsymfony/http-cache-bundle. That means no security response process, no CVE patching for pinned Symfony 2.x transitive dependencies, and no compatibility releases.
- What should I use instead for response caching in Laravel?
- Use Illuminate\Contracts\Cache\Repository for object and storage caching, and spatie/laravel-responsecache for full-response caching. For CDN or Varnish invalidation, a small Guzzle-based purger is enough. If you need tag-based invalidation, Laravel's cache tags plus an explicit purger cover the same ground with active maintenance.
- What replaced SonataCacheBundle in the Symfony ecosystem?
- The sanctioned successors are symfony/http-cache (with Psr6CacheStorage and the HttpCache store) and friendsofsymfony/http-cache-bundle for tag-based and BAN / BAN-with-tags invalidation. Both are actively maintained. If you have a legacy Symfony 2 or 3 service that depends on this bundle, plan a replacement rather than a bridge.
- Can I keep the cache key and purge design without the bundle?
- Yes, and that is the recommended path. Define a small interface in your application code, for example cacheKey(string $namespace, array $params) and flush(array $keys), back the keys with Laravel's cache repository, and back flush with an HTTP purger. That preserves the one architectural idea worth keeping — deterministic cache keys plus explicit invalidation — while discarding the Symfony container baggage.
- Something in my composer.lock pulls this package in — what do I do?
- First find out what requires it, since nothing should resolve it transitively in a modern Laravel app. Check whether it was surfaced by a scanner rather than an actual dependency, and confirm whether a legacy Symfony 2/3 service depends on it. If a real dependency exists, replace it with symfony/http-cache on the Symfony side or a native Laravel cache plus purger on the Laravel side. Do not write a provider that boots Symfony's DI container around the bundle.
- Is the license a problem, and how do I evaluate this fork?
- The MIT license is clean, so licensing is not the blocker. The decisive issues are provenance and maintenance: archived repository, no dependents, undocumented fork delta, and abandoned upstream. Before any decision, confirm whether there is an actual caching requirement (response cache, ESI fragments, or CDN/Varnish purge), who owns the fork, and what the diff against upstream looks like. The recommendation is not to adopt.