Caching
tinymash uses disposable caches to avoid repeated filesystem scans and Markdown rendering. Content, configuration, users, and media remain authoritative; cache files do not.
Main cache layers
- The content index supports routes, listings, page trees, and entry lookup.
- The rendered-content cache stores converted summaries and full Markdown bodies.
- The anonymous public page cache stores complete public HTML when the response is safe to reuse.
- The media metadata index speeds up attachment and image lookup.
- Compiled templates avoid repeated template compilation.
Anonymous public pages can use the complete HTML cache. Logged-in, private, secret-link, and otherwise personalized views bypass it. Those views still benefit from the content index, rendered-content cache, media index, and normal browser caching for authorized media.
Dynamic public fragments can disable complete page caching so changing output is not frozen into HTML.
Clear caches
php8.4 bin/tinymash.php cache:clear
Use this after manual filesystem changes, a cache-format problem, or an upgrade instruction that requires it. Normal content and settings mutations invalidate the relevant caches automatically.
Clearing a cache can make the first following request slower while derived data is rebuilt. It does not delete published content or media.
Warm caches
php8.4 bin/tinymash.php cache:warm
Warm one author space and its entries:
php8.4 bin/tinymash.php cache:warm --author=cajo --entries --entry-limit=50
--base-url overrides the configured public URL for warming. --userpass=USER:PASSWORD allows the warmer to pass through whole-site HTTP Basic authentication; keep that command out of shared shell history and logs.
Cache warming is optional. A correctly configured site rebuilds missing cache data when needed.
Browser caching
Public managed media is cacheable. Authorized media on a non-public site uses private browser caching with revalidation so page-to-page navigation remains smooth without permitting shared caches to store protected files.
Theme and plugin assets use local versioned URLs. A changed asset receives a new version value after deployment; custom overrides are not fetched from a CDN.