lzb/cache_expiration
Sets how long the prepared block list stays in a transient, or turns that transient off.
Lazy Blocks reads every lazyblocks post on each request, prepares its controls and stores the result under the lzb_blocks_cache_ transient for a day. Shorten that while you are debugging a lzb/block_data handler, or return 0 on a site whose object cache already keeps transients in memory.
Attributes
| Name | Type | Description |
|---|---|---|
$cache_expiration | Int | transient lifetime in seconds, DAY_IN_SECONDS by default |
Usage
function my_lzb_cache_expiration( $cache_expiration ) {
// No transient while a developer is editing block code, one hour otherwise.
if ( defined( 'WP_DEBUG' ) && WP_DEBUG ) {
return 0;
}
return HOUR_IN_SECONDS;
}
add_filter( 'lzb/cache_expiration', 'my_lzb_cache_expiration' );The value is compared with > 0 and then passed straight to set_transient(), so 0 and any negative number skip the write and every request rebuilds the list from the database. Only blocks stored in the database go into the transient. Blocks registered from PHP with lazyblocks()->add_block() are appended after the cached list is read, so their data is rebuilt on every request regardless of this value.
The transient key is lzb_blocks_cache_ followed by an MD5 of the registered control types and the number of callbacks on lzb/block_data and lzb/block_defaults, so activating a plugin that adds a control or a filter produces a new key rather than a stale list. lzb/cache_cleared fires whenever the plugin deletes those transients.