How QCDR Respects Joomla Access When Reading Dynamic Data

QCDR dynamic-data Tokens do not treat a saved record ID as permission to expose that record. At runtime, Joomla article, field, module, and menu providers compare the record against the current visitor's Joomla view levels and relevant publication state before returning a value.

This matters because the same Token can resolve for one visitor and remain unavailable for another. QCDR's non-destructive failure behavior helps prevent an inaccessible dynamic source from erasing authored content.

Visitor View Levels Are Part of the Lookup

QCDR builds the lookup from the Joomla view levels already available in the current request. A dynamic record must use one of those Access levels. If the visitor does not have an eligible level, QCDR treats the source as unavailable.

This is a runtime visibility check, not an Administrator preview of what a privileged account can see. Always test with the actual guest or user group that will receive the page.

Article Checks

An article must be published, be inside its publish-up/publish-down window, and use an available Access level. QCDR also checks that its Joomla content category is published and uses an Access level available to the visitor.

For a custom field, the field itself must be a published com_content.article field with an available Access level. The requested value must also exist for the article.

Menu and Module Checks

Specific menu items and modules must be frontend records, be published, be inside their publication dates, and use an Access level available to the visitor. The provider reads those records only after those checks succeed.

A specific module lookup does not evaluate whether Joomla would render that module in the current position/menu assignment; it reads the eligible stored record. Use Token page targeting when QCDR output should be limited to particular frontend pages.

Current-User Sources

Current-user ID, display name, and username are available only for an authenticated user. They do not resolve for guests. The Joomla data builder does not offer password, session, authentication token, or user-email providers.

What Happens When Access Fails

An unavailable Joomla data source is not converted to a misleading empty value during Token eligibility checks. A direct standalone Token placeholder remains in authored content, and a Rule that depends on the Token leaves the original Rule match unchanged.

That distinction is especially useful when troubleshooting: an unchanged placeholder or Rule target can indicate an access/publication/context problem rather than a replacement engine failure.

Caching Still Matters

Joomla Access is checked when QCDR renders the request. A reverse proxy, CDN, or full-page cache can still serve already-rendered output to a different visitor if the cache is not varied correctly. Treat access-sensitive or user-specific Token output as personalized content when designing caching rules.

Verification Checklist

  1. Test as a guest when Public access is expected.
  2. Test as a user in each relevant Joomla Access group.
  3. Confirm the source record and, for articles, its category are published and within dates.
  4. For custom fields, verify the field machine name/ID and field Access level.
  5. If the Token remains authored, troubleshoot the source's availability before changing the Rule or Token content.

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.