Legacy QCTNH Control Endpoints vs the Current Worker Path

Older QCTNH control endpoints remain in 2.0.3 for compatibility, but the normal production worker no longer performs a QCTNH callback/status preflight before waking Joomla.

Current worker path

  1. Site registers its exact native Joomla WebCron endpoint and WebCron key outbound to QuantaCade.
  2. When due, the worker validates/loads that registration.
  3. The worker calls the native Joomla WebCron endpoint directly with the hash credential.
  4. Joomla selects/runs its eligible task.
  5. The local QCTNH plugin can send a webcron_complete check-in with refreshed timing.

Legacy compatibility paths

Signed QCTNH actions such as older verify/status/sync-WebCron control operations may still exist for compatibility. The legacy direct nudge action is retired and returns HTTP 410 explaining that Joomla WebCron is now the execution transport.

Why documentation emphasizes current path

Administrators should troubleshoot the registered native WebCron request, not look for a proprietary QCTNH execution endpoint that no longer drives normal wake-ups.

Current vs legacy behavior

For Legacy QCTNH Control Endpoints vs the Current Worker Path, treat 2.0.3 behavior as authoritative over older QCTNH descriptions. The retired round-trip test task/direct-nudge execution model is not the current worker path. Native Joomla WebCron is the execution transport and the worker no longer requires a QCTNH callback/status preflight before each wake-up.

Compatibility endpoints/tables may still exist in source for safe upgrades or historical operations; their presence does not make them the primary customer workflow.

Community Discussion

Want to compare scheduler workflows, share practical tips, or discuss how you use this QCTNH feature? Visit the QC Task Nudge & Health Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.