How Caching Actually Works in jekcms

jekcms's caching is simpler than a lot of larger CMS platforms: there is one general-purpose Cache class (native/includes/Cache.php) backed by the filesystem, and one layer built on top of it that matters for day-to-day performance — page cache.

Page Cache: The Layer That Matters

When PAGE_CACHE_ENABLED is true (the default in production), the full HTML response for a request is written to a cache file keyed by the request URI. Subsequent requests for the same URL are served straight from that file, bypassing PHP and the database entirely. Admin pages, POST requests, and requests from logged-in users all bypass the page cache automatically — you never see cached content behind a login.

There Is No Separate Query Cache Layer

Some CMS platforms add a distinct query-result cache on top of page cache — a layer with its own TTL, its own file naming, its own settings. jekcms does not. There is one cache mechanism, and page cache is what sits in front of your database queries: once a page is cached, the queries that built it are not re-run until the cache entry expires or is cleared. If you need to cache the result of a specific expensive query yourself, outside of full-page caching, you can use the same Cache class directly (get(), set(), remember()) inside your own theme or plugin code, but jekcms does not ship a dedicated, separately-configured query cache tier out of the box.

Configuration

Page cache behavior lives in config/config.php:

define('CACHE_ENABLED', true);
define('CACHE_LIFETIME', 3600);      // default TTL for general cache
define('PAGE_CACHE_ENABLED', IS_PRODUCTION);
define('PAGE_CACHE_LIFETIME', 300);  // 5 minutes

The default 300-second page cache TTL works well for most sites. Sites that publish frequently should reduce it; sites that update content rarely can safely raise it to reduce server load.

Clearing the Cache

Cache invalidation happens automatically on post save, update, and delete through the admin panel. If you need to force it manually — after a bulk database operation, for example — call cache()->flush() from a PHP script; it takes no parameters and clears the entire file cache in one call. The admin panel's cache-clear action does the same thing.

Debugging Cache Issues

• Admin changes not appearing on the frontend: the page cache is serving a stale response. Clear the cache from the admin panel, or wait for the TTL to expire.
• Direct SQL changes not reflected: if you update data outside jekcms's normal save path (direct SQL against the database), any page cached before that change keeps serving the old content until it expires or you clear the cache manually.
• Logged-in users seeing cached content: this should never happen — page cache explicitly skips requests with an active session. If you see it, check that nothing is calling the page-cache write path from inside an authenticated request.

Because there is only one cache mechanism to reason about, debugging stays simple: if something looks stale, it is almost always the page cache, and a single clear-cache action resolves it.