Wp Cubi Transient Cache Laravel Package

Getting Started

Install it as a Composer dependency in your theme or custom plugin — this is a library, not a plugin, so nothing activates it for you:

composer require globalis/wp-cubi-transient-cache

Make sure your project loads vendor/autoload.php (Bedrock/Sage/Timber projects already do). If the package registers global helper functions via Composer's files autoload, they will be callable anywhere after autoload; if it exposes a class instead, instantiate it once in your bootstrap and inject it where needed.

Where to look first: the README for the exact helper/class names and the group/expiration argument order, then src/ — the package is small enough to read end-to-end in ten minutes. Note how it wraps get_transient/set_transient and whether it keeps a per-request runtime array on top.

First use case — wrap an expensive remote call so it runs once per hour instead of once per page view:

$forecast = cache_remember(
    'weather-zagreb',
    fn() => wp_remote_retrieve_body( wp_remote_get( 'https://api.example.com/weather?city=zagreb' ) ),
    'remote-api',        // group
    HOUR_IN_SECONDS      // expiration
);

The value persists across requests because it lands in a transient (options table, or your object cache if one is configured), and the group prefix keeps related keys tidy and bulk-invalidatable.

Implementation Patterns

Remember-around pattern. Prefer the remember-style call over manual get/set: it handles the miss, the write, and the runtime memoization in one place, so a single request never recomputes the same key. Only drop to raw get/set when you need to cache null or want to separate the "compute" and "store" steps.

Group + version prefix on deploy. Groups are typically just key prefixes, so treat them as namespacing, not as tags. Pair a group with a version constant so a deploy invalidates everything at once without touching the DB:

const CACHE_VER = '2024-06-01'; // bump on deploy

$key = CACHE_VER . ':' . get_the_ID();
cache_remember( $key, $builder, 'product-json', DAY_IN_SECONDS );

Invalidate on write hooks. Cache invalidation belongs next to the mutation, not in the read path:

add_action( 'save_post_product', function ( $post_id ) {
    cache_delete( CACHE_VER . ':' . $post_id, 'product-json' );
} );

If the library only gives you per-key delete, track the keys you generate (or delete by re-deriving them deterministically from the entity ID).

Encapsulate it. Wrap the package behind one small class — App\Cache\ProductCache with get(), flush() — so the rest of the code never calls the library directly. This makes testing trivial and swaps to a different cache backend a one-file change if the package stalls (last release 2023, two stars — treat it as a thin, replaceable dependency).

Warm the cache out-of-band. Transients are lazy. Add a WP-CLI command or cron job that pre-builds the hot keys so no shopper ever eats the cold-start cost:

WP_CLI::add_command( 'app warm-cache', function () {
    foreach ( get_posts( [ 'post_type' => 'product', 'numberposts' => -1 ] ) as $p ) {
        cache_delete( CACHE_VER . ':' . $p->ID, 'product-json' );
        ( new ProductCache() )->get( $p->ID ); // repopulate
    }
} );

Expose a force-refresh flag. Admin "clear cache" buttons and debug URLs are much easier when every read accepts a $force boolean that bypasses the runtime and persistent layers.

Run a real object cache. The whole value proposition changes with Redis/Memcached behind wp_cache_*: transients become fast and don't pollute wp_options. Without one, you're writing rows to the options table on every miss.

Gotchas and Tips

• Miss vs. false. WordPress returns false for both "not found" and "cached false". Check how the library signals a miss — if it doesn't, cache a wrapper array like ['value' => false] or you'll silently re-run expensive builders forever.
• Key length. option_name is 191 chars; WP hashes overlong transient keys, which quietly breaks your cache_delete calls if you compute the key differently. Keep group + key short and deterministic.
• Autoload bloat. Without a persistent object cache, every transient is a wp_options row. Expired ones are only cleaned on access, so schedule wp transient delete --expired and watch autoload size — this is the most common way small transient caches degrade a site.
• Expiration is a hint, not a guarantee. Transients can be evicted early (object cache pressure) or linger past their TTL. Never treat the presence of a value as proof it's fresh for anything correctness-critical.
• No tag invalidation. Groups are key prefixes. There's no "delete all in group" unless you track keys or version the group name — assume you must do that bookkeeping yourself.
• Runtime memoization staleness. If the library layers a per-request array over transients, a value written by a cron or another request won't appear until the next request. Use the $force path in tests and admin tooling.
• Multisite. Transients are per-site. Wrap switch_to_blog() around cache operations if you're caching network-wide data, otherwise you'll get cross-site misses.
• Stampede. A small library like this has no locking. On a cold cache with high traffic, N requests will all run the builder. Stagger expirations with jitter or pre-warm to avoid it.
• PHP compatibility. Released April 2023 — verify it runs cleanly on your PHP 8.2/8.3 (dynamic properties, deprecations) before adopting. CI with -d error_reporting=E_ALL is a quick check.
• Pin and vendor. With two stars and no active releases, commit a version constraint and be prepared to fork. The source is small; composer patch or a vendored copy is a low-cost escape hatch.
• Debugging. Inspect _transient_* rows in wp_options (or your Redis keyspace) and use Query Monitor's cache panel to confirm hits vs. misses per request. If a key never hits, suspect key-length hashing or a group prefix mismatch.