QCDR Source-File Safety: What Runtime Replacement Can and Cannot Change

Current QCDR 1.1.05 changes rendered Joomla frontend output in memory. It does not patch PHP files, template files, extension source, article source records, or Joomla core files when a Rule runs.

That runtime boundary makes Rules reversible: disable the Rule or live processing and the next uncached Joomla render returns to the underlying source output.

Current Rules Are Rendered-Output Only

New and edited QCDR Rules use the rendered-output location. The save path rejects attempts to create a new source-file Rule, including a forged request that posts source_files. Historical pre-current records may retain an old source-file value for compatibility, but that is not a supported current workflow.

QCDR Does Not Include a File Patcher

The runtime System plugin receives Joomla's generated HTML and transforms that response. It does not open template PHP, CSS files, JavaScript files, component source, module source, or Joomla core files and write changes back to disk.

QCDR also does not rewrite article/template database content merely because the rendered page was changed. The next request starts from Joomla's current stored/source data again.

What “PHP Source” in Find Type Does Not Mean

The current editor still has a PHP source Find content-type label, but the Rule location remains rendered output. Selecting that label does not make QCDR inspect .php files or pre-render PHP source. It can only match text that exists in the final rendered buffer.

If the PHP code itself must change, use the appropriate Joomla override, extension setting, child-template/custom code workflow, or vendor-supported source change instead of QCDR.

Administrator Is Outside the Runtime Target

QCDR deliberately does not transform Joomla Administrator output. That gives you a recovery boundary even when a frontend Rule is wrong. Use Administrator to disable the offending Rule, Token, or live-processing switch without depending on the affected frontend page.

When Runtime Replacement Is the Right Tool

Use QCDR when the requirement is to alter what an eligible frontend request renders: replace visible output, inject reusable content, target a component/module region, vary output by audience or schedule, or make a reversible presentation/runtime change.

Use a permanent source/configuration change when the underlying PHP logic, stored content, schema, template source, build asset, or extension implementation itself must change.

Verify the Boundary Yourself

  1. Create a Draft Rule against a distinctive frontend rendered string.
  2. Preview it and confirm the browser output changes.
  3. Inspect the underlying Joomla article/template/source file and confirm it is unchanged.
  4. Disable the Rule and purge relevant caches if needed.
  5. Reload the page and confirm the underlying Joomla output returns.

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.