Debug should **NOT** be enabled for production sites as it can result in system configuration and authentication information being exposed to unauthorized visitors.
Debug should **NOT** be enabled for production sites as it can result in system configuration and authentication information being exposed to unauthorized visitors.
CiviCRM has a debug mode which can be enabled to give you quick access
to a couple of useful diagnostic tools, including access to all the
...
...
@@ -74,32 +30,28 @@ to empty the file based cache and session variables.
Available debug commands are listed in the info box below.
Debug output is triggered by adding specific name-value pairs to the CiviCRM query string **when Enable Debugging is set to Yes**:
**Debug URLs**
Debug output is triggered by adding specific name-value pairs to the CiviCRM query string **when Enable Debugging is set to Yes**:
- Smarty Debug Window - Loads all variables available to the current page template into a pop-up window. To trigger, add *&smartyDebug=1* to any CiviCRM URL query string. Make sure you have pop-up blocking disabled in your browser for the CiviCRM site URL.
- Session Reset - Resets all values in your client session. To trigger, add *&sessionReset=2*
- To empty template cache (civicrm/templates\_c folder), add *&directoryCleanup=1*
- To remove temporary upload files (civicrm/upload folder), add *&directoryCleanup=2*
- To cleanup both, add *&directoryCleanup=3*
- Stack Trace - To display a stack trace listing at the top of a page, add *&backtrace=1*
- Display Current Session - Displays the current users session variables in the browser, *&sessionDebug=1*
- Smarty Debug Window - Loads all variables available to the current page template into a pop-up window. To trigger, add `&smartyDebug=1` to any CiviCRM URL query string. Make sure you have pop-up blocking disabled in your browser for the CiviCRM site URL.
- Session Reset - Resets all values in your client session. To trigger, add `&sessionReset=2`
Sometimes using *&smartyDebug=1* to inspect variables available to a template will not work as expected. An example of this is looking at the Contact Summary page using this method will display the variables available only to the summary tab and you might want to see the variables available to one of the other tabs. To do this, after you have overridden the correct .tpl file, simply add {debug} to any part of the file and the Smarty Debug Window will display all variables in the same scope as the {debug} statement.
Sometimes using `&smartyDebug=1` to inspect variables available to a template will not work as expected. An example of this is looking at the Contact Summary page using this method will display the variables available only to the summary tab and you might want to see the variables available to one of the other tabs. To do this, after you have overridden the correct .tpl file, simply add `{debug}` to any part of the file and the Smarty Debug Window will display all variables in the same scope as the `{debug}` statement.
Sometimes using *&smartyDebug=1* to inspect variables available to a template will not work as expected. An example of this is looking at the Contact Summary page using this method will display the variables available only to the summary tab and you might want to see the variables available to one of the other tabs. To do this, after you have overridden the correct .tpl file, simply add {debug} to any part of the file and the Smarty Debug Window will display all variables in the same scope as the {debug} statement.
Sometimes using `&smartyDebug=1` to inspect variables available to a template will not work as expected. An example of this is looking at the Contact Summary page using this method will display the variables available only to the summary tab and you might want to see the variables available to one of the other tabs. To do this, after you have overridden the correct `.tpl` file, simply add `{debug}` to any part of the file and the Smarty Debug Window will display all variables in the same scope as the `{debug}` statement.
You can also force the backtrace to be printed at any point in the code
by adding a call to "CRM\_Core\_Error::backtrace();"
by adding a call to `CRM_Core_Error::backtrace();`
### Settings which modify CiviCRM behavior for debugging
The following values can be added to your site's settings file
**Output all email to disk files OR discard**\
define('CIVICRM\_MAIL\_LOG', 1);\
This setting causes all outbound CiviCRM email to be written to files on your server's disk drive (Send Email to Contacts, Contribution and Event receipts, CiviMail mail ...). No real emails are sent. Emails are written to the files/civicrm/ConfigAndLog/mail (Drupal) or media/civicrm/ConfigAndLog directory (Joomla) by default.
This setting causes all outbound CiviCRM email to be written to files on your server's disk drive (Send Email to Contacts, Contribution and Event receipts, CiviMail mail ...). No real emails are sent. Emails are written to the `files/civicrm/ConfigAndLog/mail` (Drupal) or `media/civicrm/ConfigAndLog` directory (Joomla) by default.
define('CIVICRM\_MAIL\_LOG', '/dev/null');\
This setting causes all outbound emails to be discarded. No email is sent and emails are NOT written to disk.
