Combine QCDR Page, Extension, Audience, Schedule, IP, and Condition Targeting

QCDR targeting gates stack to make a Rule or Token more specific. A configured item must qualify for its page scope, extension scope, audience, schedule, IP rules, and technical conditions before QCDR applies it at that frontend location.

Use the fewest gates that express the real requirement. Layered targeting is powerful, but an unnecessary gate can make a correct Rule appear inactive.

Understand How the Gates Combine

Top-level targeting is effectively restrictive: each configured gate must allow the current request. The All selected conditions must match / Any selected condition may match choice applies only to the technical-condition lines; it does not turn page, audience, schedule, or IP targeting into alternatives.

Know Which Plan Adds Each Layer

  • Basic: page/menu/URL targeting for core Rules and plain-text Tokens.
  • Pro: component/site-module targeting, audience targeting, and schedules/recurrence.
  • Max / All Access: IP targeting and additional technical conditions.

An item can require a higher tier for other reasons too, such as its Token output type or a nested Token dependency. QCDR evaluates the effective requirement from the saved configuration rather than only the feature you most recently edited.

Build a Predictable Combined Target

  1. Start with the page or menu scope that identifies where the change belongs.
  2. Add component or site-module targeting only when the same page contains output that must be treated differently.
  3. Add audience targeting when the output must differ for guests, logged-in users, or selected Joomla groups.
  4. Add scheduling when eligibility changes by date or time.
  5. Add IP Include/Exclude rules only when the visitor network is part of the requirement.
  6. Add technical conditions last for request/Joomla context that the higher-level controls do not already express.
  7. Test one request that should qualify and one that should not.

How QCDR Evaluates the Request

The runtime applies its frontend safety boundary first, then checks page scope, audience, schedule, IP rules, and technical conditions. Extension targeting is evaluated against the current component/module render region: Rules search only eligible regions, while a standalone Token checks the render region containing that placeholder. Only after those gates qualify does QCDR perform the actual Rule match or Token resolution.

Diagnose an Item That Does Not Run

For a saved Rule, Preview & Rule Health is the fastest way to inspect the major gates. It reports page/menu targeting, component/module targeting, audience, schedule/timezone, IP Include/Exclude, and additional-condition results separately.

Also verify the item is Enabled, its required tier is available, the appropriate Live Processing switch is on, and cached output is not hiding a request-specific result. Audience- or IP-dependent output should not be placed behind a cache that serves the same HTML to visitors who are supposed to receive different results.

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.