In Moodle 1.7 there are two new things that will help you debug code:
1) $CFG->debug can have a more precise range of values so you can choose more exactly what sort of messages you want to see. It sets the PHP error level as well as the Moodle error level. See the Debugging page under the new admin menu.
2) A new debugging function in weblib.php that will print debugging messages. You should always use this function in code instead of directly accessing $CFG->debug.
/**
* Returns true if the current site debugging settings are equal
* to the specified level: E_NOTICE, E_ALL, E_STRICT etc
* eg use like this:
*
* 1) debugging('a normal notice');
* 2) debugging('something really picky', E_STRICT);
* 3) if (debugging()) { echo "a bunch of commands could be here" }
*
* @param string $message a message to print
* @param int $level the level at which this debugging statement should show
* @return bool
*/
function debugging($message='', $level=E_NOTICE) {
global $CFG;
if (empty($CFG->debug)) {
return false;
}
if ($CFG->debug >= $level) {
if ($message) {
notify($message, 'notifytiny');
}
return true;
}
return false;
}
We are discussing this a bit with MartinD -- the third use mentioned above, where it says:
if (debugging()) { echo "a bunch of commands could be here" }
actually breaks debugging significantly. There are two modes of debugging with PHP:
- you can get debug messages in your webpage. this is practical to get started, and when you cannot access the server easily. It has a significant downside: it breaks XHTML, cookies, general http headers, and Javascript.
- you can get your debug messages in the apache errorlog, syslog or in a php-configured logging file. This is slightly harder to do, but much more powerful, and lets you run full debugging messges without modifying the output of moodle to the browser. This means you can get your messages without causing breakage.
Now, with the current implementation of debugging() the second mode, which is the one you really need to debug stuff in a XHTML and AJAX world, is broken. I am working to fix that. However, every case where we are doing
if (debugging()) {
is we have to turn around and _avoid_ printing stuff directly. In most cases, just doing debugging("message") is enough.
if (debugging()) { echo "a bunch of commands could be here" }
actually breaks debugging significantly. There are two modes of debugging with PHP:
- you can get debug messages in your webpage. this is practical to get started, and when you cannot access the server easily. It has a significant downside: it breaks XHTML, cookies, general http headers, and Javascript.
- you can get your debug messages in the apache errorlog, syslog or in a php-configured logging file. This is slightly harder to do, but much more powerful, and lets you run full debugging messges without modifying the output of moodle to the browser. This means you can get your messages without causing breakage.
Now, with the current implementation of debugging() the second mode, which is the one you really need to debug stuff in a XHTML and AJAX world, is broken. I am working to fix that. However, every case where we are doing
if (debugging()) {
print or echo or var_dump some stuff
}is we have to turn around and _avoid_ printing stuff directly. In most cases, just doing debugging("message") is enough.
Right-O.
in HEAD now we have a New! Improved! debugging() that does TheRightThing (I think) most of the time. It is controlled by $CFG->debugdisplay (now available at your admin->server->debug page) which mimics PHP's display_error.
What is left now is to go through the use of debugging()
grep -r -A4 'debugging()' * | less
in HEAD now we have a New! Improved! debugging() that does TheRightThing (I think) most of the time. It is controlled by $CFG->debugdisplay (now available at your admin->server->debug page) which mimics PHP's display_error.
What is left now is to go through the use of debugging()
grep -r -A4 'debugging()' * | less