How QCDR Preserves Authored Content When a Token Is Unavailable

QCDR treats an unavailable Token differently from a Token that intentionally produces an empty value. When QCDR knows a Token exists but it cannot be used in the current request, the runtime is designed to preserve the administrator's original authored content instead of silently replacing it with blank output.

This protection applies to direct Token placeholders, nested Token dependencies, and Rules whose replacement depends on a Token.

Why a Token Can Be Unavailable

A stored Token can be unavailable because it is Disabled, Draft, Archived, locked by the current Effective tier, outside its page/extension/audience/schedule/IP/condition scope, dependent on another unavailable Token, or unable to obtain the required request-time Joomla data.

PHP Tokens have an additional protected failure path: when PHP execution fails and the Token's error mode is Hide, QCDR treats that output as unresolved rather than as a successful empty value.

Direct Placeholders Stay Authored

During standalone Token processing, QCDR remembers the names of stored Tokens even when those Tokens are not currently eligible. If the rendered page contains a known placeholder such as {company.phone} and that Token is unavailable, QCDR leaves the exact placeholder untouched.

The same is true when targeting or a dynamic-data provider does not qualify at that location. An unavailable Token is not automatically converted to an empty string.

Dependent Tokens Fail as a Chain

Before resolving a Token that contains other Token references, QCDR checks whether the required dependencies are available in the current context. If a required inner Token fails, the outer Token is also unavailable. This prevents output such as a partially built sentence or HTML fragment with one missing dependency from replacing the authored placeholder.

Rules Preserve Their Matched Text

When a Rule uses a Token as its replacement, QCDR checks Token eligibility for the specific match location. If the Token is unavailable, the Rule skips that match and leaves the original matched text intact.

The same protection applies when a Rule's direct replacement text embeds one or more Token references: if a required Token cannot qualify, QCDR does not apply the partially resolved replacement.

Unavailable Is Not the Same as Intentionally Empty

A valid Token can legitimately resolve to an empty value—for example, a source that is available but contains an empty string. That is different from QCDR being unable to resolve the Token safely. The preservation behavior protects failure/unavailability; it does not force visible output when a valid source intentionally contains no text.

Use Preservation as a Diagnostic Signal

If a literal Token placeholder remains visible where you expected a value, check the Token status, Effective tier, targeting, schedule, dependencies, and dynamic-data availability before editing the page content. For a Token-backed Rule, check whether the original target text remained unchanged; that often indicates the replacement Token was not eligible rather than that the Rule failed to find its target.

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.