Laravel Model Improved Laravel Package

Getting Started

1. Install the package (composer require <vendor>/autocache) and publish its config:

   php artisan vendor:publish --tag=autocache-config
   

2. Look first at config/autocache.php, then at the package's service provider. As of 1.3.0 the config now exposes toggle flags for AutoCache — these are the first thing to read, because they decide whether anything else in the package is active in a given environment.
3. Set the master toggle explicitly per environment. The intended baseline after 1.3.0 is roughly:

   // config/autocache.php
   'enabled' => env('AUTOCACHE_ENABLED', true),
   'toggles' => [
       'queries' => env('AUTOCACHE_QUERIES', true),
       'models'  => env('AUTOCACHE_MODELS', true),
       'http'    => env('AUTOCACHE_HTTP', false),
   ],
   

   Treat the exact key names as illustrative — confirm against the package README before shipping, since the 1.3.0 notes only describe the capability, not the key names.
4. First concrete use case: wrap one expensive read path (a dashboard aggregate, a menu/nav builder, or a slow where(...)->get() on a reference table) and confirm with Cache::getStore() / your cache driver that hits are actually being served from cache. Don't enable AutoCache globally on day one; enable it behind the new flags for one code path, observe hit rate, then widen.

Implementation Patterns

Config-driven toggles as the default. Use the 1.3.0 flags as your primary control surface rather than editing code. Wire them to env vars so each environment (local, CI, staging, prod) can differ without a deploy of application code. .env.example should carry the toggles explicitly so new developers don't inherit surprising defaults.

Runtime toggles for scoped work. Where the package exposes runtime enable/disable (facade or trait method), use them at the boundaries of a request rather than mid-domain-logic:

// In a middleware — cache reads for GET, never for mutations
public function handle($request, Closure $next)
{
    AutoCache::enabled($request->isMethod('GET') && ! $request->user()?->isAdmin());

    try {
        return $next($request);
    } finally {
        AutoCache::enabled(config('autocache.enabled')); // restore
    }
}

Always restore state in a finally; long-lived processes (Octane, queues) will otherwise leak the toggle into the next request or job.

Feature-flag rollout. The new toggles compose naturally with Laravel Pennant or a simple config/DB flag: enable AutoCache for a percentage of users or a single tenant, compare query counts and response times, then flip the global default. This is the single highest-value use of 1.3.0 — it turns AutoCache from an all-or-nothing decision into a measurable experiment.

Per-context discipline. Recommended split:

Test suite pattern. Disable globally in phpunit.xml via the env var, then write one or two focused tests that enable AutoCache and assert invalidation behaviour (write → read returns fresh data). This keeps the bulk of your suite fast and deterministic while still covering the caching contract.

Invalidation as a first-class concern. Whatever toggle state you run in production, define invalidation up front: model saved/deleted events, explicit Cache::forget/tag flushes on admin actions, and a deploy hook that clears AutoCache keys when cached payload shapes change. Toggles control whether caching happens — they do not control whether stale data is correct.

Gotchas and Tips

• Config cache and env parsing. env('AUTOCACHE_ENABLED', true) returns the string "false" if someone writes AUTOCACHE_ENABLED=false into a cached config in some setups, and non-empty strings are truthy. Cast with (bool) / filter_var(..., FILTER_VALIDATE_BOOL) in the config file, and remember php artisan config:cache freezes the toggle until you re-cache.
• Toggling off does not evict. Disabling AutoCache stops new reads/writes but leaves existing entries in the store. If you disable because of suspected stale data, flush the relevant keys/tags as well, or you'll re-enable into the same bad state.
• Octane / long-running workers. Anything that reads config or the toggle once at boot (service provider, singleton) will not see per-request changes. Resolve the toggle at call time and avoid constructor-injected booleans.
• Cache store capabilities. Tag-based invalidation and flush behave differently across file, database, redis, and array drivers. file and database do not support tags — if your invalidation strategy depends on tags, pin the store to Redis/Memcached in the environments where the toggle is on, and add a boot-time guard that fails loudly on an incompatible combination.
• Middleware ordering matters. A toggle middleware registered after auth won't see the user (breaking user-scoped toggles); one registered after the route middleware won't affect that route. Register it early in the web/api group.
• Debugging. Start with the cache store itself: Cache::getStore(), key inspection via your driver's CLI (redis-cli --scan --pattern '*autocache*'), and Laravel Telescope's cache panel to confirm hits vs misses. Then check the resolved toggle value with a dd(config('autocache')) in a tinker session — misconfigured flags are the most likely cause of "the package isn't caching anything."
• Extension points. Prefer the package's published config plus events/hooks over forking. If you need custom key derivation or per-model TTLs, look for a config-level key strategy or a model-level trait/attribute before reaching for a decorator around the cache repository.
• Don't let toggles become permanent debt. Flags added for a rollout should have an owner and a removal date. A toggle that has been false in prod for six months is dead configuration; delete it.