Caching

When you make a change in the RKHM admin panel — publishing an item, updating a setting, editing a page — it doesn't always appear on the live site immediately. This is expected: several caching layers sit between the database and your visitors' screens, each holding onto data for a little while to keep the site fast. This page explains what those layers are, how long each one typically holds onto data, and what you can do if you need a change to show up right away.

The caching layers

Between an admin action and what a visitor actually sees, a request can pass through up to five caching layers:

1. RKHM's built-in cache — stores frequently-read data (widget content, dashboard counts, site settings) directly in the database, for a few minutes at a time.
2. A service worker — runs in the visitor's browser and stores scripts, styles, images and API responses for offline use and faster repeat visits.
3. The browser's own HTTP cache — separate from the service worker, governed by standard cache headers.
4. Cloudflare — only relevant if you've put your site behind Cloudflare's caching/CDN service. RKHM doesn't manage this for you.
5. Nginx — only relevant if your server uses Nginx with its own response caching in front of RKHM. Also outside RKHM's control.

Not every installation uses all five. Cloudflare and Nginx are pieces of your own server setup, not something RKHM installs or configures — if you don't use them, only the first three layers apply.

RKHM's built-in cache

This is the one layer that's always part of RKHM, on every installation. It quietly caches some of the data it reads most often, so pages don't have to re-query the database on every request. It expires purely on a timer — nothing you do in the admin panel proactively clears it early, so a change can take up to the times below to become visible:

• Widgets like "related items" on a content page: up to 10 minutes
• Counters and badges pulled from the database (e.g. a pending-items count): up to 10 minutes
• Admin dashboard graphs: up to 5 minutes
• The site-wide settings bundle — site name, logo, social links, mobile navigation: up to 5 minutes

Most individual setting values outside that bundle take effect on the very next page load — there's no meaningful delay for those.

If you have direct access to your site's database, this cache lives in a single table, _bof_cache_db, and holds nothing but temporary, derived data — it's always safe to clear it manually if you need a change to appear immediately and don't want to wait out the timer.

The service worker

RKHM registers a service worker in visitors' browsers to speed up repeat visits and support offline playback. It keeps its own copy of scripts, styles, pages, images, fonts and API responses, each for a set amount of time before it's considered stale:

• Scripts, styles and pages: up to 7 days
• Images: up to 3 days
• Fonts: up to 90 days
• Everything else: up to 5 days

These timers don't hold back updates. Every script and style is requested with your installation's version number, and pages and the app's configuration are always fetched from the network first while the visitor is online, so after you update RKHM visitors get the new files on their next online visit. The timers only decide how long a copy stays available when the visitor is offline. Items visitors save for offline playback aren't affected by them either: they stay until the visitor deletes them.

The browser's HTTP cache

RKHM doesn't set aggressive caching rules for most of what it serves — there's no long expiration header on your content or API responses. The one thing that is cached this way is your site's main script bundle, tagged with a version number that only changes when you update RKHM itself. Browsers can hold onto that bundle indefinitely between updates, which is why a hard refresh sometimes helps right after updating your installation.

Cloudflare and Nginx

If your production server sits behind Cloudflare's caching or a caching layer in Nginx, know that RKHM does not automatically purge either of them when you make a change. Content can stay stale behind them until their own cache rules expire, or until you purge them yourself through the Cloudflare dashboard or your Nginx configuration. This is entirely separate from everything above, and outside what RKHM itself controls.

Getting a change to show up right away

• For anything covered by RKHM's built-in cache (widgets, counts, dashboard graphs, settings), the only way to see the change sooner than its normal timer is to wait it out, or — if you have database access — empty the _bof_cache_db table directly (for example with phpMyAdmin's Empty action).
• For your own browser during testing, a hard refresh usually isn't enough on its own if the service worker already has a cached copy; clearing your browser's site data for the domain (or forcing the service worker to update) will get you a clean copy.
• For Cloudflare or Nginx, purge their caches through their own tools — RKHM has no built-in integration to do this for you.

Local development

If you're running RKHM locally for testing or development, most of this doesn't apply: the built-in cache, the settings bundle, and browser cache-busting are all switched off automatically while the installation is in development mode, so changes generally appear on the very next reload. The one exception is dashboard counts and graphs, which still run on their normal 5–10 minute timers even in development mode.