Allow QCDR Processing in Protected Script, Style, and Code-Like Areas

QCDR protects high-risk rendered regions by default. Max and All Access Rules can deliberately enable Allow matching inside script, style, code, or other normally protected areas, but this removes an important runtime safety boundary and should be tested privately first.

What QCDR Protects by Default

Normal Rule matching skips complete script, style, code, pre, textarea, template, noscript, and svg blocks. It also skips complete form blocks and ordinary HTML comments. QCDR’s own internal boundary-marker comments are treated separately.

This protection reduces the chance that a text replacement accidentally corrupts JavaScript, CSS, embedded code, form markup, templates, or other sensitive response content.

Enable Protected-Area Matching

  1. Save the Rule in Draft or Disabled state first.
  2. Under Processing behavior, enable Allow matching inside script, style, code, or other normally protected areas.
  3. Keep the Rule’s page/extension/audience scope as narrow as practical.
  4. Save the Rule.
  5. Use Preview & Rule Health on the exact frontend URL before enabling ordinary runtime processing.

This Is a Rule Feature, Not a Standalone-Token Escape Hatch

Standalone Token resolution remains deliberately conservative: it does not scan protected blocks or HTML tag/attribute markup. The protected-area option belongs to the Rule matcher. Use a Rule when you intentionally need to transform technical rendered content.

Understand the Risk

A syntactically small replacement can have a large effect inside JavaScript, CSS, forms, or template-like markup. A wrong quote, delimiter, selector, variable name, or partial match can break the page or change application behavior. Limit occurrences and targeting wherever possible, and keep Joomla Administrator available as the recovery surface.

Use Rule Health to See the Safety Boundary

During authorized Preview, Rule Health reports when matching occurrences were intentionally skipped by protected-area safety. When the bypass is enabled, Rule Health identifies that protected-area matching is active. This lets you distinguish “the text is not present” from “the text exists but QCDR correctly protected it.”

Production Checklist

  • Preview the exact saved Rule first.
  • Test the affected script/style/form behavior, not just the visible page text.
  • Test representative guest and logged-in requests when context can differ.
  • Review Joomla/CDN caches before concluding that the new rendered output is consistent.
  • Know that disabling the Rule or Rule Live Processing removes the runtime transformation without editing the underlying source file.

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.