Read QCDR Rule Health Diagnostics

Rule Health explains why the selected saved Rule would or would not produce a live match for the same frontend request. QCDR 1.1.05 builds the checks from the actual request context and the saved Rule configuration rather than from a static checklist.

Read the rows in order: early targeting failures can prevent search matching from being attempted, while Token or Discovery warnings can explain why an otherwise matching Rule is not ready to publish.

Core Request and Targeting Checks

  • Published / enabled: whether the Rule is currently Enabled for normal live requests. Draft/Disabled can still be privately previewed.
  • Frontend safety scope: confirms the request is eligible frontend output rather than Joomla Administrator output.
  • Page / menu targeting: checks the current menu item and URL/path against the Rule scope.
  • Component / module targeting: confirms an eligible render region exists for the configured extension target.
  • Audience: checks the current user/session against Everyone, Guests, Logged-in users, or Joomla-group targeting.
  • Schedule / timezone: evaluates start/end, recurrence, local time windows, and blackout dates.
  • IP Include / Exclude: evaluates the current resolved client IP.
  • Additional conditions: evaluates the Rule's technical conditions and All/Any logic.

Token Readiness

Direct replacements with no Token dependency pass Token readiness immediately. Token-backed or embedded-Token replacements are checked for an available published Token and the Token's own targeting. Joomla dynamic-data Tokens are also checked to confirm the configured Joomla record/source is available and accessible for this request.

Discovery Target Fingerprint

If the Rule carries a fingerprint created by Discovery, Rule Health adds a Discovery target row. It can report an exact target, a likely changed target, a missing target, or legacy/invalid advisory evidence. This row never changes the Rule automatically.

Search Text and Occurrence Selection

After the request qualifies, QCDR reports how many eligible matches were found and how many replacements were selected by the Rule's occurrence controls. If a targeting gate failed, the Search text row explains that matching was not applied. If targeting passed but no occurrence was found, the row reports a genuine no-match result.

Protected Areas

Rule Health reports whether protected-area bypass is intentionally enabled, how many otherwise matching occurrences were skipped inside protected markup, or that no match was blocked by protected-area safety.

Live Result

The final row summarizes whether the Rule would currently produce a live match for the same request. An Enabled Rule with passing targeting and at least one match can pass; an unavailable replacement Token can still make the final result fail. If the literal Rule still matches but its Discovery fingerprint has drifted, QCDR can downgrade the final status to informational so you review the advisory warning before publishing changes.

Plan Locks Are a Separate Gate

Rule Health does not contain a generic “plan tier” row. A Rule whose required tier is unavailable can be skipped before detailed Rule Health is generated. If Preview produces no normal health rows, first confirm the Rule's required tier and current Effective Tier before troubleshooting individual targeting checks.

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.