How the QCDR Runtime Engine Processes Frontend Output

QC Dynamic Replacer works on Joomla's rendered frontend HTML. The package-owned System plugin marks frontend component/module render boundaries while Joomla builds the page, then the RuntimeEngine evaluates eligible Rules and Tokens against the completed response before Joomla sends it to the browser.

It does not edit Joomla source files, article text, template files, or extension PHP as part of normal runtime processing.

1. QCDR Waits for an Eligible Frontend HTML Request

The System plugin runs only when QCDR's runtime boundary accepts the request. Administrator output, non-HTML document types/formats, and protected frontend user login/reset/remind views are excluded. If both Rule and Token Live Processing are off, ordinary live transformation is skipped.

2. Joomla Render Boundaries Are Marked Internally

During frontend rendering, QCDR can place inert internal markers around the dispatched component output and rendered module output. Those markers let extension targeting understand where output came from after the template assembles the full page. Ordinary visitors never receive the markers; QCDR strips them before delivery.

3. QCDR Builds Request Context

The engine records the current frontend component/view, menu item, URL/path/hostname, language/template, request method/query, guest/user/group/view-level data, current article ID when applicable, client IP, current UTC time, and private Preview/Discovery state. Targeting gates use that request context.

4. Enabled Rules Run in Deterministic Order

Normal runtime loads enabled rendered-output Rules ordered by priority ascending, then Rule ID ascending. For each Rule, QCDR checks its required plan and targeting gates before searching the response. Token-backed replacement output is not resolved speculatively; QCDR first confirms that the Rule has real selected matches.

Occurrence selection, per-Rule replacement limits, protected-region safety, and the request-wide replacement ceiling can all reduce the number of actual replacements. Stop Processing stops later Rules only when the current Rule actually made at least one replacement.

5. Standalone Tokens Resolve After Rules

After Rule processing, enabled standalone Token placeholders are resolved in eligible visible output when Token Live Processing is enabled. This pass is independent of Rule ordering and Stop Processing. It is conservative around HTML tags/attributes and protected script/style/code/form/comment areas.

6. Safety Limits and Failure Handling Apply to the Whole Request

Before transformation QCDR enforces the configured Maximum HTML response size. During processing it enforces the request-wide maximum replacements. If an unexpected runtime exception escapes the normal item-level safeguards, QCDR logs a warning and returns the original marker-free Joomla output instead of delivering a partially processed response.

What This Means for Troubleshooting

When a change does not appear, determine which stage prevented it: request boundary, live-processing switch, plan gate, targeting, search/occurrence selection, Token readiness, protected area, per-Rule/global limit, or safe failure. Preview and Rule Health expose many of those stages without changing the live Rule state.

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.