Troubleshooting a New Frontend Tab That Does Not Become the Target User

Troubleshooting a New Frontend Tab That Does Not Become the Target User requires identifying whether the problem is in plugin visibility, target eligibility, the short-lived handoff, or the separate frontend session before changing configuration.

Diagnostic procedure

  1. Read any Joomla message in the new tab; invalid/expired tokens and changed eligibility produce explicit errors.
  2. Confirm Joomla Shared Sessions is disabled.
  3. Confirm the target is still eligible and the issuing administrator remains a Super User.
  4. Check that the site session handler can fork sessions and write session metadata.
  5. Create a fresh handoff rather than reusing the old tab/token.

Keep the layers separate

This occurs after the handoff starts. Separate token-consume errors from Joomla session-fork/session-handler problems and from later banner asset rendering.

Information to preserve

Record Joomla/QCUI versions, exact message, plugin state, issuer authorization, target eligibility, and whether the original administrator tab remained authenticated. Exclude passwords and raw handoff secrets.

When to escalate

If Troubleshooting a New Frontend Tab That Does Not Become the Target User persists after the documented layer is verified, stop creating repeated handoffs and preserve the exact error/context. A private support case should include version/state evidence but never passwords, session cookies, MFA secrets, or raw QCUI tokens.

Community Discussion

Want to compare support workflows, share practical tips, or discuss how you use this QCUI feature? Visit the QC User Impersonation Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.