ProcessWire WireCache: lazy fallback caching with TTL and backend handling

Use $cache->get with a fallback closure and a TTL that matches your edit cycle

The practical approach for reducing database load in ProcessWire is to wrap expensive reads in WireCache with a lazy fallback closure and a TTL that reflects how often the underlying content changes. WireCache stores values in your configured backend (file, database, or memcached) and executes the fallback only on a cache miss, so you avoid redundant computation.

Pattern to use in a template or module

$cache = $this->wire('cache');
   $key = 'expensive_posts_' . $page->id;
   $posts = $cache->get($key, function () use ($page) {
       // runs only on cache miss
       return $page->children()->filter('status=1')->find();
   }, 300);
   

How WireCache stores and invalidates entries

WireCache writes entries to the backend you configure. With the file backend, entries live under sites/cache. With the database backend, entries live in wire_cache. Expiration is enforced on read. ProcessWire also clears cache entries automatically when the associated page or template is modified through the API, which helps keep data fresh without manual invalidation.

Backend selection is made in site/config.php. Typical options are file, database, or memcached. File backend requires write permission for the web user on sites/cache. Database backend requires the wire_cache table to exist.

Verification approach without claiming test results

Create a temporary page, save a value with $cache->save('test_key', 'value', 300), then request the page twice. The second request should return the cached value from WireCache rather than recomputing. Inspect the cache backend directory or database table after requests to confirm entries exist and age out after the set TTL.

Limits and common mistakes

• Serialization cost. Complex data structures are serialized via PHP serialize before storage. Large objects increase write and read cost and memory use. Cache only scalar values or small arrays of primitives.
• Non-serializable values. Storing resources such as database connections, open file handles, or objects with circular references will cause runtime errors on save or retrieval. Convert objects to arrays before caching.
• TTL choice. Very short TTLs, for example under 60 seconds, can negate benefits because recomputation happens frequently. Align TTL with content change frequency.
• Stale content. Automatic clearing on page or template edit helps, but manual edits to data outside ProcessWire's API, or caching user‑specific data with a shared key, can serve stale content. Include user ID or role in the key when data varies per user.
• Cache key collisions. Keys must be unique strings. Use a namespace prefix and identifiers to avoid collisions across features.