Use Rule Health to Diagnose Targeting and Token Readiness

When a Rule Preview does not behave as expected, Rule Health lets you separate a request-targeting problem from a search-value problem or a replacement-Token problem. Fix the first failed gate instead of changing several Rule settings at once.

The diagnostic uses the exact saved Rule and the real frontend request, so changing the test URL, login state, time, IP, or Joomla context can legitimately change the result.

Start with the Request-Targeting Gates

  1. Check Frontend safety scope. QCDR does not process Administrator output.
  2. Check Page / menu targeting for the selected menu item and URL/path.
  3. Check Component / module targeting to confirm the intended rendered region exists on this response.
  4. Check Audience for the actual current frontend session.
  5. Check Schedule / timezone, including recurrence/windows/blackouts.
  6. Check IP Include / Exclude using QCDR's resolved client IP.
  7. Check Additional conditions for request/Joomla context mismatches.

If one of these gates fails, the Search text row reports that search matching was not applied. Correct the failed gate or use a representative URL/request before changing the Rule's find value.

If Targeting Passes but Search Text Fails

A no-match result means QCDR reached the targeted rendered region but did not find an eligible occurrence of the saved search value. Confirm the exact rendered HTML/text, Exact vs Partial matching, case sensitivity, component/module scope, and whether the apparent match sits inside protected markup.

Use Protected-Area Information

If Rule Health reports matching occurrences skipped inside protected markup, the Rule search value exists but the default safety boundary prevented replacement. Do not turn on protected-area bypass simply to make a check green. First confirm that changing script/style/code-like/form/template markup is intentional and that the Rule is Max-level and narrowly targeted.

Then Read Token Readiness

  • Missing/unpublished Token: create/publish the intended Token or select the correct replacement source.
  • Token targeting does not qualify: compare the Token's own audience, schedule, IP, conditions, page, and extension targeting with the preview request.
  • Joomla data unavailable: verify the configured record exists, is published, and is accessible to the current visitor.
  • Direct replacement: Token readiness should pass without a dependency.

Remember the Rule State

A Draft or Disabled Rule intentionally fails Published / enabled. Preview may still show the transformation, but the final Live result should not claim it would run normally until you enable the Rule.

Plan Locks May Appear Before Rule Health

If the Rule itself requires a tier above the current Effective Tier, QCDR can skip it before the detailed health rows are built. Confirm entitlement first when a saved Rule produces no useful health detail despite a valid preview request.

Change One Variable and Preview Again

After each correction, save the Rule and launch a fresh preview. That prevents an unsaved editor change or an old 15-minute preview authorization from confusing the result and makes it clear which change fixed the failing gate.

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.