Cache TTL

Settings → Markdown Alternate → General

How long a generated Markdown document is kept in the cache before being rebuilt from scratch.

Default: 86400 seconds — 24 hours. 0 disables the cache entirely.

What is cached

The converted document, per post. Building one means rendering the post’s blocks, running the DOM passes and converting the result to Markdown, so caching it saves real work on a popular article.

Where it is stored depends on your site: if a persistent object cache is available (Redis, Memcached) the plugin uses it, otherwise it falls back to transients. You do not configure this — it is detected.

Why the value matters less than it looks

Two things blunt it in practice.

Edits do not wait for the TTL. Saving a post clears that post’s entry immediately, and saving the settings page clears every entry. The TTL is a ceiling on how long a stale document can survive an event the plugin did not see — not a delay between your edit and the published result.

The conversion is not the slow part. On a measured 18 KB article the whole conversion stage runs in under 10 ms, against roughly a second of WordPress boot for the same request. Turning the cache off does not make responses feel slow; the boot dominates either way.

So the honest advice is to leave it alone. The default is a reasonable ceiling, and moving it up or down changes very little.

When to change it

Set it to 0 while you are tuning the exclusion lists. Every request then rebuilds, so you see the effect of a change immediately without saving the settings page to force it. Put it back afterwards.

Raise it if you have a very large site on a slow host and articles are edited rarely. The gain is modest, for the reason above.

Conditional requests are not affected

Turning the cache off does not turn off 304 responses. The validator sent with each document is computed from the post’s modification date and the plugin’s settings, not from the cached body, so a client holding a current copy still revalidates cheaply even with the cache disabled.

That is the part worth keeping: ETag handling and the body cache are independent, and the first one is where most of the bandwidth saving lives.

From code

Two filters, both taking seconds:

// The per-post Markdown documents.
add_filter( 'sysmda_markdown_cache_ttl', function ( int $ttl, WP_Post $post ) {
  return 'product' === $post->post_type ? HOUR_IN_SECONDS : $ttl;
}, 10, 2 );

// The /llms.txt index.
add_filter( 'sysmda_llms_txt_cache_ttl', function ( int $ttl ) {
  return 6 * HOUR_IN_SECONDS;
} );

Returning 0 or less from the first one disables the body cache for that post.