Understand Protected Regions and Runtime Output Contexts in QCDR

QCDR normally protects browser-sensitive markup while it searches rendered Joomla HTML. Script, style, code-like blocks, forms, SVG, templates, comments, and similar regions are skipped by ordinary Rules unless a Max-level Rule explicitly opts into protected-area processing.

Rules and Tokens also format replacement values differently depending on the selected output type and target context. Understanding those boundaries helps prevent a visually simple replacement from becoming invalid HTML, CSS, JavaScript, or an unsafe attribute value.

What QCDR Protects by Default

When protected-area processing is off, Rule matching skips complete <script>, <style>, <code>, <pre>, <textarea>, <template>, <noscript>, <svg>, and <form> regions. Ordinary HTML comments are protected as well.

This is deliberate. Matching a word that happens to appear inside JavaScript, CSS, a form control, or code sample can change browser behavior even when the same word is safe to replace in visible page text.

Standalone Tokens Are Even More Conservative

Standalone {token.name} replacement does not scan protected regions or HTML tag/attribute markup. It is intended for placeholders in visible rendered output. If you need to change a URL, attribute fragment, CSS, JavaScript, or another technical context, use an explicit Rule so the target is deliberate and testable.

How Output Types Are Formatted

  • Plain text: HTML-sensitive characters are escaped while leaving normal text readable.
  • HTML: trusted configured markup is returned as HTML.
  • URL or attribute output: values are attribute-escaped.
  • CSS / JavaScript Tokens: when used in ordinary HTML they emit a <style> or <script> wrapper; when a Rule targets the matching CSS/JavaScript context, the raw code is used.
  • Image and Link/Button Tokens: QCDR builds the appropriate HTML markup and rejects dangerous URL schemes.

The current editor also exposes Find content-type labels such as Text, HTML, CSS, JavaScript, PHP source, and URL. These labels do not change QCDR into a source-file scanner; every current Rule still searches rendered output.

Protected-Area Opt-In Requires Max

A Rule can opt into protected areas only when the current Effective tier permits the Max feature. That setting removes the default region exclusion for the Rule; it does not make a risky replacement intrinsically safe. Use a narrow search value, restrictive targeting, and conservative occurrence limits.

Test Browser-Sensitive Changes Before Enabling Them

  1. Save the Rule as Draft or Disabled.
  2. Use private Preview on the exact frontend page where the target appears.
  3. Inspect the browser result, console, layout, form behavior, and links—not only the QCDR replacement count.
  4. If the change targets CSS/JavaScript or protected markup, test more than one representative page and device state.
  5. Enable the Rule only after the rendered page remains valid.

Preview shows QCDR behavior on the saved Rule; it does not sandbox JavaScript or PHP side effects.

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.