Review Joomla and CDN Caching When QCDR Output Varies by User or IP

QCDR evaluates targeting against the request that reaches Joomla, but a full-page cache or CDN can reuse previously generated HTML for later visitors. If QCDR output varies by login state, Joomla group, IP address, query/request context, dynamic user data, or time, shared caching can defeat the intended audience boundary.

Normal QCDR live responses do not automatically receive the private/no-store headers used by QCDR Preview and Discovery.

Why Shared Page Caching Can Change the Result

QCDR runs late in Joomla's frontend render cycle. On a cache miss, Joomla/QCDR can build the correct variant for the current request and the cache layer may then store that final HTML. If the cache key does not include the context QCDR used, a later visitor can receive that stored variant without QCDR getting another chance to evaluate the request.

This is especially important with CDN/reverse-proxy caches that operate before PHP/Joomla.

Treat These QCDR Features as Cache-Sensitive

  • Guest vs logged-in audience targeting.
  • Joomla-group audience targeting.
  • IP allow/deny targeting.
  • Request/query/method or other technical conditions.
  • Current-user Joomla data Tokens.
  • PHP Tokens or Rules that intentionally produce request-specific output.
  • Schedules, blackout dates, or other time-sensitive changes when cache TTL can outlast the change boundary.

Choose a Cache Strategy That Matches the Variant

For pages that must vary by private/user/IP context, the safest approach is usually to exclude those pages from shared full-page caching unless your cache/CDN can reliably segment its cache key using the same context. Do not assume a URL-only cache understands Joomla groups or QCDR IP targeting.

For site-wide Rules that produce the same output for every visitor, ordinary page caching is usually less problematic because the cached variant is intentionally universal. You still need to account for cache TTL when a Rule is changed, scheduled, enabled, or disabled.

Purge After Material QCDR Changes

When you enable, disable, or materially edit a Rule/Token that affects cached pages, purge the relevant Joomla/page/CDN caches or wait for their TTL before judging the live result. Otherwise you can mistake old cached HTML for current QCDR behavior.

Test More Than One Context

  1. Test a clean cache miss in the first target context.
  2. Request the same URL from a different user/group/IP context.
  3. Inspect cache HIT/MISS or Age headers where your CDN/proxy exposes them.
  4. Confirm each context receives the intended QCDR output rather than the first cached variant.
  5. Repeat after a cache purge to separate QCDR behavior from stale cache behavior.

Preview and Discovery Are Different

QCDR deliberately makes private Preview and Discovery responses private, no-store, no-cache and disables Joomla page caching for those diagnostic requests. Those protections do not automatically apply to ordinary live Rule/Token output, so successful Preview does not prove that a production CDN cache key is safe for personalized output.

Community Discussion

Want to compare workflows, share practical tips, or discuss how you use this QCDR feature? Visit the QC Dynamic Replacer Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.