QC Dynamic Replacer Production Go-Live Checklist

Use this checklist before relying on QC Dynamic Replacer in production. The goal is to verify the 1.1.05 package, entitlement automation, frontend runtime, targeting, caching, permissions, testing, and recovery path before broad live use.

1. Confirm Installation and Runtime Health

  • Open QC Dynamic Replacer → Status and confirm the installed version is 1.1.05.
  • Confirm the package-owned Component, System plugin, and Task plugin are present and healthy.
  • Verify the QCDR System plugin is enabled. Normal live frontend transformation depends on it.
  • Resolve any package/update warning before launch rather than accepting a partially repaired installation.

2. Verify Entitlement and Scheduled Automation

  • Confirm the production hostname is authorized for QCDR when paid features are expected.
  • Read both Base tier and Effective tier; do not assume stored paid configuration means paid runtime access is currently active.
  • Confirm Entitlement Revalidation has exactly one published canonical task scheduled at least hourly and that Joomla is actually running Scheduled Tasks.
  • If using the one-time 30-Day Max Preview, start it only deliberately. Installation, navigation, Refresh Entitlement, and normal frontend requests do not consume an unused preview.

3. Review What Is Allowed to Run

Open Rules and Tokens separately. Their Live Processing switches are independent. Confirm only the Rules and Tokens intended for launch are Enabled and that Draft, Disabled, or Archived items are not being mistaken for live content.

For PHP Tokens, verify Max/All Access is effective and limit Manage PHP Tokens to trusted administrators. PHP Tokens execute trusted server-side PHP and are not sandboxed.

4. Test Targeting on Representative Requests

Do not verify only one administrator browser session. Test the pages, menu items, components/modules, login states, Joomla groups, schedules, IP/network conditions, query conditions, and other targeting dimensions that matter to the live Rule.

For higher-impact Rules, save them first and use private Preview & Rule Health when available. Use Discovery when you need evidence about rendered output or target drift; Discovery evidence is advisory and never silently enables or retargets a Rule.

5. Review Caching Before Personalized Output Goes Live

Normal QCDR runtime output does not automatically receive the private/no-store headers used by Preview and Discovery. If output varies by user, group, IP, query, schedule, or dynamic Joomla data, configure Joomla/full-page/CDN caching so one visitor's rendered variant cannot be reused for another incompatible request.

6. Know the Recovery Path Before Launch

  • Administrator output is outside QCDR's normal runtime transformation boundary.
  • Rule Live Processing and Token Live Processing can be disabled independently or together without deleting configuration.
  • A logged-in Super User can add qcdr_bypass=1 to a frontend URL to skip QCDR for that request when the request reaches Joomla.
  • Keep a current site/database backup before major production changes.

Final Go-Live Sign-Off

Before declaring QCDR production-ready, verify a fresh uncached request for each important audience and target, confirm Rule Health has no unexplained gate failure, confirm caching behaves as intended, and confirm another trusted administrator knows how to disable processing or use the emergency bypass. A successful editor save is not the same as a verified production result.

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.