Weave Code
Laravel Responsecache Php72 Laravel Package
codeat3/laravel-responsecache-php72
A PHP 7.2-compatible fork of Laravel ResponseCache that speeds up your app by caching full responses. Store, tag, and invalidate cached pages easily, with support for middleware, cache profiles, and automatic clearing on model changes.
Spatie's laravel-responsecache forked version for php 7.2. Speed up a Laravel application by caching the entire response
Frequently asked questions about Laravel Responsecache Php72
- What is codeat3/laravel-responsecache-php72 and when should I use it?
- It is a PHP 7.2-compatible fork of Spatie's laravel-responsecache that stores the entire HTTP response and replays it on repeat requests, so controllers and database queries are skipped. It is meant for legacy Laravel applications stuck on PHP 7.2 that serve a lot of anonymous, read-only GET traffic such as marketing pages, docs, blog posts, and public listings. On PHP 7.4 or 8.x you should use the maintained upstream Spatie package instead, since this fork exists only to bridge the PHP 7.2 gap.
- Which PHP and Laravel versions does this fork support?
- The fork targets PHP 7.2, which is the whole reason it exists, but you should read the composer.json inside the fork itself for the exact PHP patch constraint and Laravel version range. Do not infer compatibility from upstream Spatie releases, because the fork may lag behind upstream bug fixes and framework version bumps. Verify the declared constraints against your app before planning any rollout.
- How do I install and configure laravel-responsecache-php72?
- Require it with Composer, publish the config file, register the middleware alias, and apply the middleware to a route or route group. Then create a CacheProfile class if you need to control which requests qualify, for example gating on Auth::guest() and rejecting query strings or preview cookies. You can confirm it works by checking that hasBeenCached() flips to true on the second request to a cached route.
- Can I install it next to spatie/laravel-responsecache?
- No. The fork reuses Spatie's Spatie\ResponseCache namespaces, so it is a drop-in replacement rather than a co-installable peer. Remove spatie/laravel-responsecache from composer.json first, otherwise you will hit dependency conflicts or class collisions. Plan that swap explicitly in your rollout steps so nobody accidentally reintroduces upstream.
- How do I clear or invalidate the response cache in Laravel?
- The package gives you mechanisms such as ResponseCache::forget() for a single URL, clear() for everything, tag-based clearing, model observers, and plain TTL expiry, but it does not impose a policy. Decide which mechanism is authoritative for each content type and document it, because stale pages after a write or a stale authorization decision are the most common failure mode. Test that admin save events actually purge the right URLs.
- Which routes are safe to cache with full response caching?
- Only routes that are provably anonymous, read-only, and deterministic for every visitor. That means marketing pages, documentation, blog indexes, and public catalog listings, while excluding authenticated dashboards, carts, checkout, account settings, multi-tenant views, CSRF-bearing forms, preview modes, and locale or A/B variant responses. Get an explicit sign-off on the route allowlist and have someone review the cache-key and Vary handling in your CacheProfile.
- Which cache store should I use in production with ResponseCache?
- Use Redis or Memcached, because tag support and atomic invalidation matter once you clear by tag or by model. File-based caching works for a spike but becomes a correctness and performance concern under real traffic due to eviction and stampede behaviour. Decide the store before you go live so invalidation semantics do not change between staging and production.
- How do I test that response caching does not leak data between users?
- Write feature tests that hit the same URL as a guest and as an authenticated user, then assert the responses differ and that no session or cookie data bleeds through. Cover CSRF tokens, redirects, Vary headers, preview and admin cookies, and confirm that a model save actually purges the affected URLs. Use hasBeenCached() to assert hits and misses, and run these tests on the same cache store you use in production.
- Is this package maintained, and should I use Spatie's original instead?
- It has almost no external validation, with very few stars and no dependents, and the fork may not track upstream fixes, Laravel compatibility changes, or security advisories. If you are on PHP 7.4 or higher, use the maintained upstream Spatie package without question. If you are stuck on PHP 7.2, treat this as an internal fork you own: pin the version, vendor the code, read the cache-key logic, and name an engineer accountable for patches.
- What are the alternatives if I cannot upgrade past PHP 7.2?
- The strongest alternative is upgrading PHP and Laravel and using maintained upstream packages, since a response cache fork is not worth a permanent support burden. If that is not possible, consider narrower optimisations such as route, view, or query caching, or full-page caching at the CDN or nginx layer for truly static pages. A custom middleware limited to a small allowlist is also safer than blanket whole-response caching.
Weaver
How can I help you explore Laravel packages today?