- Can I install pablok/supercache-bundle in a Laravel application?
- No. It is a Symfony bundle that registers a store service and a DI compiler pass for Symfony's HttpCache kernel wrapping pattern, and Laravel has no equivalent bundle or HttpCache store extension point. Composer may resolve the package, but nothing in Laravel would consume its service definitions. For Laravel, use spatie/laravel-responsecache, a custom response cache middleware, or a CDN.
- What does SuperCacheBundle actually do?
- It provides a filesystem-backed implementation of Symfony's HttpCache StoreInterface so full HTTP responses can be persisted to disk. That gives you reverse-proxy-style caching without standing up Varnish or a CDN edge. The bundle itself is small, consisting of a cache store, a config tree, and a compiler pass, and it does not patch the kernel or override routing.
- Which Symfony versions does SuperCacheBundle support?
- The release window maps to Symfony 4.1/4.2, and it targets the Symfony 2/3/4 HttpCache model. Its composer.json constraints will almost certainly block Symfony 5, 6, and 7 because the CacheInterface and StoreInterface signatures changed. Treat it as a Symfony 4.x-only dependency.
- Is pablok/supercache-bundle still maintained?
- No. The repository is archived, has a single star, zero dependents, and no release since December 2018. There is no second maintainer and no upstream to route a bug report or CVE to. Any security review of its dependency graph is now your responsibility.
- How do I install and configure it in a Symfony 4 app?
- You require it with Composer, enable the bundle in your kernel, and point framework.http_cache at the bundle's custom store.service id with a few lines of YAML. That is a sanctioned Symfony extension point rather than a hack against internals. Realistically, expect to fork it into a first-party namespace and use a VCS constraint rather than a plain composer require.
- Will SuperCacheBundle work with Symfony 5, 6 or 7?
- Very unlikely. A 2018-era store implementation will not satisfy the newer StoreInterface and CacheInterface signatures, and the Composer constraints will typically refuse the install. Plan on a fork-and-patch exercise if you must run it on a modern Symfony release.
- Is SuperCacheBundle safe to run in production?
- Treat the risk as high. The package is abandoned, its transitive dependencies have not been reviewed since 2018, and correctness bugs in a cache store are asymmetric because they serve wrong bytes with a 200 rather than degrading gracefully. Disk-based HTTP caches are also exposed to stampede and lock contention under concurrency.
- Does SuperCacheBundle handle cache stampede and lock contention?
- There is no evidence that the 2018 implementation includes thundering-herd protections. Disk-backed HTTP caches are particularly vulnerable to stampede and lock contention when many requests miss the same entry at once. If you fork it, budget time to add and test locking yourself.
- What should I use instead in Laravel for full page caching?
- Use spatie/laravel-responsecache or a custom response cache middleware for full-response caching, and put a CDN in front for static assets and edge caching. Laravel's own cache stores and HTTP cache headers cover most make-pages-faster requirements. The build-versus-buy math changes once you drop the Symfony HttpCache model.
- Should I fork SuperCacheBundle or write my own HttpCache store?
- The store implementation is MIT licensed and small, and the delta over a thin in-house StoreInterface implementation is probably around 200 lines. Vendoring the logic into an internal package with tests and dropping the upstream dependency is usually the cleanest exit path. If you stay on Symfony, also evaluate symfony/http-cache and FOSHttpCache before adopting anything unmaintained.