Weave Code
Laravel Remember All Laravel Package
barchart/laravel-remember-all
A Laravel package that remembers all query string parameters across requests, making it easy to preserve filters, sorting, and pagination as users navigate away and back.
A Laravel session driver to remember all devices a user has logged in with.
Frequently asked questions about Laravel Remember All
- What does barchart/laravel-remember-all actually do?
- It reintroduces a remember()-style caching primitive on top of the Eloquent query builder, an ergonomic API Laravel removed back in 5.8. It extends that idea with a rememberAll() call that caches a full query chain, plus a global or per-model opt-in so existing call sites do not need to change. Cache keys are derived from the generated SQL and its bindings, and entries expire by TTL only.
- How do I install it in a Laravel application?
- You add it with composer require barchart/laravel-remember-all, optionally publish the config, and optionally add the trait to the models you want cached. Mechanically the integration is small: one Composer dependency, an optional config publish, and an optional trait, with no migrations or schema changes. Check the resolved version against your framework version before you rely on it, since the package has no releases past Laravel 9.
- Which Laravel and PHP versions does this package support?
- It declares Laravel 8+ and PHP 8+, and its final release in September 2022 existed specifically to add Laravel 9 support. There is no Laravel 10, 11, or 12 path and no validation against PHP 8.2 or 8.3. Treat the supported window as closed at Laravel 9.
- Is barchart/laravel-remember-all still maintained?
- No. The repository is archived, has roughly 29 stars, and has seen no releases in more than two years. There will be no fix if a framework upgrade breaks it and no advisory if a security flaw is found. If you adopt it, your team owns the code whether or not it owns the repository.
- How does cache invalidation work in this package?
- It does not, beyond TTL. Keys are built from the SQL and its bindings and entries expire on a time-to-live, with no described hook into model events, so a write does not evict the cached read. Any read that must reflect a just-committed write, such as a balance, an eligibility check, or an authorisation lookup, silently turns into a stale read.
- Is it safe to use with multi-tenant applications?
- Only if every tenant-scoped query binds a tenant identifier into the query itself. Keys derived from SQL and bindings do not account for tenancy applied through session state, global scopes, or connection-level switching, so those queries can collide with another tenant's cached result. That is a data-leak class of bug rather than a performance one, and it should be reviewed as a security question before enabling anything globally.
- Should I use global mode or opt in per model?
- Global mode makes caching the default for every read on a model, decided once at config level and inherited silently by code paths nobody audited. Only enable it if you can enumerate exactly which reads are consistency-tolerant. Otherwise use explicit per-model or per-call-site opt-in so the caching decision stays visible next to the query.
- Will this cause a cache stampede or Redis capacity problems?
- A TTL-only scheme with per-query keys produces high key cardinality and synchronised expiry, so a popular model's cache can expire and drop the full read load on the database at once. Global mode also turns a modest number of instrumented reads into a very large number of cached ones. Treat adoption as a capacity-planning change for your cache store, not just an application change.
- What are the alternatives to this package?
- Wrapping specific queries in Laravel's own Cache::remember() gives you the same effect with explicit, auditable opt-in and no abandoned dependency. For response-level caching there are actively maintained packages, and for read-heavy paths a read replica or materialised view may fit better. Because the code surface is reportedly small, vendoring or reimplementing it in-house is also realistic.
- Should we run this in production and what is the migration risk?
- Only on Laravel 8 or 9 with PHP 8.x, and only for reads you have confirmed are consistency-tolerant. The surface is small enough that vendoring or reimplementing it removes the abandonment risk entirely. Before adopting, check whether the package is already pinned anywhere in your estate and on which services and framework versions, and confirm whether it degrades gracefully to the database when the cache store is unavailable or fails the request.
Weaver
How can I help you explore Laravel packages today?