Some php clips I keep in in my development editor scrapbook. Useful for debugging php code in concrete5 development.

To dump a php variable or any object to the browser, this snippet wrapping print_r() can be used anywhere after a view had been started. In a view or view template itself, in an add or edit dialog, or even in the associated controller, including the save() and validate() methods . If used before the view has started it can result in a browser complaining about a duplicate header, but who cares if it shows the critical clue!

echo "<pre>";
echo "********************\n";
echo htmlentities(print_r($data,true));
echo "\n====================";
echo "</pre>";

$data can be any php variable or object. Sometimes even dumping $this or $controller can help work out what is going on. The addon Quick Param View uses a variation of this code to dump $_POST and other php globals.

The dumped info can be obscured by the dashboard bar, in which case a few extra "\n" after the opening pre can move it down into the display.

Sometimes displaying the info simply won't work, isn't convenient, or you need a record of what is going on. This is where the concrete5 log class comes in useful. In its simplest form, you can just insert a log call to dump scalar data:

Log::addEntry($scalar_data);

addEntry accepts a second parameter that defaults to 'debug'. Sometimes it can be useful to insert the calling function name, or any text tag you want to help keep track:

Log::addEntry($scalar_data, __FUNCTION__ );
Log::addEntry($scalar_data, 'Here' );

With more complex data, the print_r function will dump the entire structure as with the echo to display above:

Log::addEntry(print_r($data,true));

If the $data object contains anything that could be mis-interpreted and rendered as html, then you can escape it as:

Log::addEntry(htmlentities(print_r($data,true)));

Most of the time, I prefer to use the unescaped version as, unless there are html entities in the data, it fits the log display better.

If you want to know how the code got to a particular point, you can create a stack backtrace and then dump it to the log, but be careful about this as it can get incredibly verbose:

Log::addEntry(print_r(debug_backtrace(),true));

Having put debug information into the log, you can view it through the dashboard log page. Or sometimes, especially when developing a block, its more convenient to view it on a front end page with Quick Log View.

For more detailed diagnostics, the addon Quick Stack View provides a helper that can be used for a complete stack dump with formatted output.

Read more How-tos by JohntheFish