- What does graham-campbell/cache-plugin actually do?
- It is an HTTP cache plugin, not a cache-store extension. It wraps a PSR-18/HTTPlug HTTP client and stores complete PSR-7 responses in a PSR-6 cache pool, replaying them on subsequent matching requests. That makes it useful for outbound calls to metered APIs, scheduled syncs, and SDK-style clients rather than for caching Eloquent queries or Blade fragments.
- Does graham-campbell/cache-plugin work with Laravel's Http facade out of the box?
- No. The plugin decorates a PSR-18/HTTPlug client, while the Http facade is Guzzle-based, so nothing is wired automatically. You either bind a decorated client instance, build an equivalent Guzzle handler, or route outbound vendor calls through a small typed service that owns the decorated client. The third option ages best because it keeps caching policy out of controllers.
- How do I install graham-campbell/cache-plugin with Composer?
- Run composer require graham-campbell/cache-plugin. There is no Laravel service provider or package auto-discovery, so you register the plugin yourself in a service provider or a small factory class. You also need a PSR-6 pool implementation and a PSR-18/HTTPlug client in the same application.
- Which PSR-6 cache pool should I use with this plugin in Laravel?
- Laravel's Cache repository is not PSR-6, so bind an adapter such as symfony/cache or a cache/adapter wrapper around a Laravel store, or use Redis or Memcached directly. Remember that the pool serializes whole PSR-7 responses, including bodies and streams, so the adapter's serialization behaviour matters. Keep it as a separate pool from your application cache to avoid surprises.
- Does the plugin honour Cache-Control, no-store, private, Vary, and ETag revalidation?
- The plugin respects response cache directives by default, including no-store, private, no-cache, max-age, and Vary, and it understands ETag and Last-Modified for conditional requests. This behaviour is configurable through the options array, so you can also force a fixed TTL. Verify directive handling in the exact version you install, because it is the difference between correct caching and serving stale user data.
- How does the cache key work, and is it safe for multi-tenant or per-user responses?
- The default key generator hashes the request URI together with a configured list of headers, typically Accept, Accept-Encoding, Accept-Language, and Authorization. Tenant or user identity is therefore only part of the key if it travels in one of those headers. If you scope responses by tenant, locale, or user, extend the header list or write a custom CacheKeyGenerator.
- What PHP and framework versions does graham-campbell/cache-plugin support?
- It is a framework-agnostic PHP package, so it follows the PHP and PSR constraints declared in its composer.json rather than a Laravel version matrix. Check the require block for the PHP range and the psr/cache and psr/http-message versions before adopting it. In Laravel terms, it works with any version whose PHP constraint you satisfy.
- Will adding this plugin break Http::fake() in my tests?
- Possibly. Http::fake() hooks into the Guzzle handler stack used by the Http facade, so if you swap in a decorated PSR-18 client for those calls, the fake no longer intercepts them. Keep fakes at the boundary of your typed outbound service, or point the plugin at an in-memory PSR-6 pool and assert on cache hits instead.
- How is this different from php-http/cache-plugin, and could I just write it myself?
- It is a Graham Campbell fork of the HTTPlug cache plugin with its own defaults and maintained release line. The core idea, decorating a client and persisting responses into a PSR-6 pool, is small: a competent engineer can reproduce equivalent behaviour in roughly 50 to 100 lines. Borrow the pattern if you want tight control, or take the package if you want those defaults and key generators ready-made.
- Is graham-campbell/cache-plugin safe to use in production?
- It is a single-maintainer package with a small surface area and no widely known dependents, so treat external validation as limited. Implementation risk is low, but pin a version, review the source, and confirm that directive handling and key generation match your use case. Keep a fallback plan, such as a thin in-house decorator, since the pattern is easy to own.