Apply Audience, Scheduling, IP, and Technical Conditions to QCDR Tokens

QCDR Tokens can use the same request-aware eligibility controls as Rules. Audience and scheduling controls require at least Pro; IP targeting and technical conditions require Max. These gates determine whether the Token is available for the current request before QCDR produces its output.

The controls are cumulative. A Token does not become eligible because one section matches while another configured section fails.

Choose an Audience

The Token editor can allow Everyone, guests only, logged-in users only, or selected Joomla user groups. For selected groups, a logged-in user qualifies when at least one of the user's Joomla groups matches the configured group list.

Using an audience other than Everyone raises a Token's effective requirement to at least Pro.

Add a Schedule

An enabled schedule can set start/end boundaries, daily/weekly/monthly recurrence, timezone-aware daily windows, and blackout dates. Any enabled Token schedule requires at least Pro. QCDR evaluates the schedule for the current request; a Token outside the active window is unavailable.

Use IP Targeting

Max-level IP targeting accepts individual IPv4/IPv6 addresses, same-family address ranges, and CIDR networks. Choose allow mode when only listed addresses should qualify, or deny mode when listed addresses should be blocked.

If the site is behind a reverse proxy, configure trusted proxy addresses carefully. QCDR honors forwarded client addresses only when the direct connection address is itself a configured trusted proxy.

Add Technical Conditions

Technical conditions are Max-level controls. Current condition types are url, menu, component, view, language, user_group, template, hostname, query, and request_method. Each line can use the default comparison or an explicit supported operator.

Condition logic controls only the condition rows: choose All when every condition must match or Any when one condition is enough. Page targeting, audience, schedule, IP rules, extension targeting, status, plan tier, and dependencies remain separate gates and must still qualify.

Understand Dependent Rule Behavior

A Rule that uses this Token does not override the Token's own targeting. If the Rule finds its target but the Token fails an audience, schedule, IP, condition, page, extension, or dependency check, QCDR leaves the original Rule match unchanged.

A directly authored placeholder behaves the same way: when the stored Token is known but unavailable in that request, QCDR preserves the literal placeholder instead of silently outputting a blank value.

Test Positive and Negative Requests

  1. Keep the Token Draft while configuring several gates.
  2. Test a request that should satisfy every gate.
  3. Change one condition at a time—such as user state, time window, IP, or URL—and confirm the Token becomes unavailable.
  4. Enable the Token only after both the positive and negative tests behave predictably.

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.