vTiger safe debugging on production environment

Sometimes it is necessary to debug or to trace the execution of vtiger. There are multiple options from logging, over db tracing, php debugging, log4php, php smarty and finally also with tracy lib.

Especially if you work with plugins for vtiger, you may face really crappy once. There are many freelancers outside, who do not really know how to implement clean and structured vtiger extensions. Instead they modify the original sources of vtiger. How to identify them? If you need to rehire them on upgrade of vtiger to newer version, you are very probable a victim of such bad implemented code, since you have to rehire them again, and what do you think how they typically fix it? Yes by corrupting once more the original sources of vtiger.

Vtiger has a clean API to use for implementing extensions, but the developers have to know this. So for this cases you will be really happy to be able to analyze the with the following debugging and logging options.

This tutorial assumes your vtiger installation is under

/var/www/vtigercrm

so if a reference to a file is ment like opening include/database/PearDatabase.php it is of course ment that you are using your vtiger installation path. So like in the given example the full path would be

/var/www/vtigercrm/include/database/PearDatabase.php

From the order of priority to try to modify logging it is recommended to go with these order of the main headings in this tutorial. Means first via log4php settings, afterwards via database and so on.

log4php configuration and usage

Here we have multiple paths to enable the better tracing, let us go through the intentional entry points.

As a good software engineer you should understand how a logging framework like log4php works and what problems it solves for you. If you do not know it already, you have coded till today really like it was coded in the 90s and first years in 2000s, so you are working on outdated knowledge!

Enable DEBUG the vtiger way

Configure debugging in vtiger at global level

vi config.performance.php

modify

'LOG4PHP_DEBUG' => false,

to

'LOG4PHP_DEBUG' => true,

Basically this sets the root logger of log4php to debug level, which means all loggers are set also to DEBUG.

The log4php way

a

Database query tracing

Many problems have the root cause on the database. So we need to be able to identify the issues via the executed queries.

There are many ways to enable the SQL tracing, but here the best practices

The hard-core way

By modifying the database access class PearDatabase we can modify the debugging of the SQLs of very section, including modules of vtiger. But use it carefully, since it impacts your log file size and of course your performance of vtiger!

vi include/database/PearDatabase.php

in this file get to the end of the file where you find this

if(empty($adb)) {
   $adb = new PearDatabase();
   $adb->connect();
}

extend it to

if(empty($adb)) {
   $adb = new PearDatabase();
   $adb->connect();
   $adb->setDebug(true);
}

As written, it will report you really EVERY SQL query!

A litte bit better way

Instead of tracing every SQL it may be helpful to trace only on errors/exceptions of the code the SQL. This maybe more helpful, if you know you are getting a programming error, if you are not facing such an error, this maybe useless to you. In this case set it to

if(empty($adb)) {
   $adb = new PearDatabase();
   $adb->connect();
   $adb->setDieOnError(true);
}

IMPORTANT

Disable the above lines after you are done with your debugging!

A better way for your modules

A much better way to do the debugging is to enable one of the both ways in your module only. Means you can limit the SQL tracing down to only the required area. E.g. on access $adb in your module, you simple append either $adb->setDebug(true); or $adb->setDieOnError(true); to your initialization of the database and you reset it it on ending/leaving your module.

Smarty template lib debugging

asdfa

Tracy library