Caching

Data and page caches

The data cache avoids repeating selected reads. The page cache stores eligible visitor-independent responses, separated by locale. Authenticated or request-specific output must not enter a shared public cache. Cache eligibility and invalidation are enforced by the framework.

For the demo, page caching is configured in src/Config/settings.json.default. Set a short TTL while editing. Clear cache after content or configuration changes; the API v2 cache flush (POST /api/v2/cache/flush) needs an integration key with the cache:write scope.

Read-only diagnostics

The CLI can inspect configuration, deployment readiness, and migration state without running database DDL:

vendor/bin/wbengine.php config:check --config=src/Config/Settings.json --root=src
vendor/bin/wbengine.php doctor --config=src/Config/Settings.json --root=src
vendor/bin/wbengine.php migration:status --config=src/Config/Settings.json --root=src

CLI and web workers can use different PHP settings and filesystem permissions. Compare their OPcache and writable-directory configuration when results differ.

The page cache in detail

The page cache serves a stored copy of a page to anonymous visitors before any box runs. The copy is kept per path, per language and per device class (mobile, tablet, desktop). A response that is private, sets a cookie or depends on the visitor is never stored, and neither is a page requested by a logged-in user, an error page or a response that a custom route produced. A page that is served from the cache carries the header X-WBengine-Cache: HIT.

/robots.txt and /sitemap.xml are generated for every request and are not stored in the page cache, so a page that was just published is in the sitemap at once.

The statistics still count a page that is served from the cache, in the language of the cached page. A change to a page reaches visitors after the cache lifetime (cache.pages.ttl, 60 seconds by default) or after a flush. See the settings reference for the keys, allowPaths and denyPaths.