HowTo: read the debug log

  • overview

    There are 3 sections of logging in the ACP.
    * the Activity Log
    * the Debug Log
    * the PHP Error Log

    The information in the Debug Log can look quite cryptic at first, so in this document we look at how to read the information in the Debug Log.
  • screenshot of the Debug Log tab in the ACP
  • example

    If all is going well your debug log will hopefully be empty.

    However while developing new modules or skins, it is quite common for mistakes in code to cause the debug log to fire.

    When somethings wrong but you don't know what it is, the Debug Log can be a useful tool to help you figure out what is wrong.

    Here is an example of an entry in the debug log.
        [0] => xtDJLicense
        [1] => Array
                [jrcore_list_function_call_is_active] => 1
                [search] => Array
                        [0] => _item_id in 
                        [1] => _profile_id IN (SELECT SQL_SMALL_RESULT `_item_id` FROM jr_jrprofile_item_key WHERE `key` = 'profile_quota_id' AND `value` IN(1,2,3))
                [limit] => 6
                [template] => xtDJLicense_stems.tpl
                [order_by] => Array
                        [_created] => DESC
                [module] => xtDJLicense
  • In this particular example it is this line of code that is causing the issue
    [0] => _item_id in 
  • To the developer who wrote the code that line of text means something.

    Perhaps they were looking for a particular id or series of ids to be returned.

    eg: _item_id in 1,2,3,4,5

    and because the set of numbers in that was supposed to get into the search query didn't get there they can know where to go to look for the problem.

    The most common reason for this would be if that section of code was populated with a variable via the templates.

    {jrCore_list module="xxSomething" search1="_item_id in 1,2,3,4,5"}

    but where 1,2,3,4,5 were assigned to a variable, say
    {$foo = '1,2,3,4,5'}
    {jrCore_list module="xxSomething" search1="_item_id in $bar"}

    With the above example the developer could see that _item_id in should read _item_id in 1,2,3,4,5 but the 1,2,3,4,5 isn't coming out so would know to check.

    A quick check would show that the wrong variable was being used $bar. Changing that to the correct $foo would sort it out in this instance.
  • Writing to the Debug Log

    If you want to send some info to the Debug Log from a module, you can do so with the fdebug() function.

    The fdebug() function takes any number of variables and writes them to the debug log.

    A nice way I like to use it is to create an array send just that array.

    It cleanly allows you to know where and when the function was fired.

    $debug = array(
        'what' => 'Im trying to figure out whats going on here.',
        '$_post' => $_post,
        '$_conf' => $_conf,
13 Feb 2014 03:38:09AM @ultrajam:
I often add an fdebug into a function to see what is being received by the function, run it once to write to the log and then remove it.
function jrCore_db_update_item($module, $id, $_data = null, $_core = null){
    global $_user;
fdebug('jrCore_db_update_item', $module, $id, $_data, $_core);

13 Feb 2014 11:57:47AM @michael:
great idea @ultrajam. ^^
24 Mar 2014 12:40:31PM @ultrajam:
You can also use fdebug in a template:
Which is very useful if you need to quickly read the contents of a variable which contains html - the fdebug popup window truncates long text strings, but you can easily use fdebug then check the log: Very cool!

11 Apr 2014 01:34:57AM @ultrajam:
Paul pointed this out here:

You can also use
debug('write to the screen',$_conf);
which will write the debug data to the screen rather than to the log. Note that this won't work for you if it's an ajax call.

Share This