PHP Tokens in QCDR: Capabilities, Risks, and Safety Boundaries

PHP Tokens are QCDR's most powerful Token type. They run administrator-authored PHP on the Joomla server and use the code's captured output as the Token result. They require Max/All Access, and administrators who create or change them need the dedicated Manage PHP Tokens Joomla permission in addition to normal Token management access.

PHP Tokens are not sandboxed. Treat their code with the same care as trusted Joomla extension code because it executes with the permissions available to the PHP/Joomla process.

What a PHP Token Can Do

Because the code executes server-side, it can call PHP functions and Joomla APIs available to the running site. Depending on server permissions and the code you write, that can include database changes, filesystem access, outbound requests, mail, logging, or other side effects.

QCDR captures what the code outputs and uses that captured text/markup as the Token result. A PHP Token may also emit other QCDR Token placeholders; those placeholders are resolved after the PHP finishes, subject to their own targeting and dependency rules.

Plan and ACL Boundaries

  • PHP Tokens require an Effective Max/All Access feature tier to execute.
  • An administrator must be allowed to manage Tokens and have Manage PHP Tokens to create/edit PHP code.
  • The PHP-specific ACL also protects status changes, deletion, and duplication of PHP Tokens.
  • A frontend visitor does not need the Manage PHP Tokens ACL. That permission controls who may administer executable Token code; runtime eligibility is controlled by the saved Token, QCDR entitlement, and its targeting.

If entitlement drops below Max, preserved PHP Token configuration remains stored but the runtime refuses to execute it.

No Sandbox

QCDR validates PHP syntax when you save the Token, but it does not restrict the PHP language to a safe subset. Runtime execution includes the saved code in a temporary server-side PHP file and therefore relies on the normal security boundary of the Joomla/PHP process.

Do not paste untrusted code into a PHP Token. Review it for destructive queries, filesystem changes, network calls, secrets, long-running work, and repeated side effects before enabling it.

Execution and Output Safeguards

The recommended execution mode is Once per page request. QCDR runs the code on first actual use of that Token, captures the raw output, and reuses it for later uses during the same Joomla request. The optional Every occurrence mode deliberately reruns the code at each actual Token occurrence or eligible Rule match.

QCDR suppresses ordinary PHP warnings/notices from being dumped directly by PHP into visitor output, removes its temporary execution file, and enforces the configured runtime body-size ceiling on captured PHP output. These safeguards do not make unsafe PHP safe.

Failure Policy

With Hide PHP errors—the recommended production setting—a PHP error or unsuppressed warning makes the Token unresolved. QCDR then preserves the authored standalone placeholder or original Rule match instead of silently replacing it with blank or partial output.

Show sanitized PHP errors is a temporary troubleshooting aid. It can place a sanitized diagnostic into frontend output, so turn it back off after testing.

Operational Guidance

  • Prefer a normal Token or Joomla dynamic-data Token when PHP is not necessary.
  • Keep PHP Tokens narrowly targeted while testing.
  • Use Once per page request unless repeated execution is explicitly required and safe.
  • Avoid code whose correctness depends on executing exactly once across multiple page requests; QCDR's request cache does not persist between requests.
  • Back up production data before deploying PHP that performs writes.

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.