Turn on log4php.debug library usage, in file config.inc.php

$LOG4PHP_DEBUG = true;

Set the log level, in file log4php.properties

log4php.rootLogger = DEBUG, A1

The log files will be written in the logs directory. For the rootLogger it will be logs/vtigercrm.log


Make sure logs/ folder has write access to apache server process owner.



When you activate the DEBUG level a lot of information gets written into the log file, among this data is the regular Activity Reminder call which is rather bothersome. You can do two things to reduce this noise.
  • go to user preferences and set the reminder to none
  • in the javascript console type
ActivityReminder_Deactivated = true;
This variable is defined in include/js/general.js around line 3100 if you want to make it permanent during your debugging session.



  • Turn on debuging for ADODB instanced in include/database/PearDatabase.php (at end of file)

if(empty($adb)) {
 $adb = new PearDatabase();


  • In file, Smarty_setup.php add the following to class constructor function

function vtigerCRM_Smarty() {
 $this->template_dir = 'Smarty/templates';
 // ...
 $this->debugging = true;

AJAX and Javascript

Global Variables

There are various debug global variables that can help you diagnose problems with your coreBOS installation.


  • What I usually do is edit the curl call and dump the raw result coming from coreBOS. Obviously the log4php system is also very useful in this case.

  • The exact code change is one of these two depending on POST or GET calls:

diff --git a/vtwsclib/Net/curl_http_client.php b/vtwsclib/Net/curl_http_client.php
index c52dd76..a42eb3c 100644
--- a/vtwsclib/Net/curl_http_client.php
+++ b/vtwsclib/Net/curl_http_client.php
@@ -183,7 +183,7 @@ class Curl_HTTP_Client
 		//and finally send curl request
 		$result = curl_exec($this->ch);
+var_dump($result); // GET
 			return false;
@@ -243,7 +243,7 @@ class Curl_HTTP_Client
 		//and finally send curl request
 		$result = curl_exec($this->ch);
+var_dump($result);  // POST
 			return false;


Also, the ajax call in the browser can be seen and is very useful also to see the raw result (Firebug is your friend)

Additionally, one of our former team members used this patch, which produces the error on screen or in the AJAX response.


Have a read here about how coreBOS outgoing email server works and how to configure it.

Activate the debug log at level FATAL and set the Debug_Email_Sending global variable to 1. This will send the whole conversation between coreBOS and the email server to the log file so you can diagnose the problem.


In previous versions, we used to need the changes below which I leave here as a reference only. The global variable method is better.


To debug the outgoing email server the best is to activate PHPMailer debugging with the changes below and look in the debug log file (logs/vtigercrm.log)

diff --git a/modules/Emails/class.phpmailer.php b/modules/Emails/class.phpmailer.php
index 8427255..61bd55c 100644
--- a/modules/Emails/class.phpmailer.php
+++ b/modules/Emails/class.phpmailer.php
@@ -326,7 +326,7 @@ class PHPMailer
      * @var integer
      * @see SMTP::$do_debug
-    public $SMTPDebug = 0;
+    public $SMTPDebug = 4;
      * How to handle debug output.
diff --git a/modules/Emails/mail.php b/modules/Emails/mail.php
index a8cac72..7674172 100755
--- a/modules/Emails/mail.php
+++ b/modules/Emails/mail.php
@@ -328,7 +328,14 @@ function setMailServerProperties($mail)
        $mail->Host = $server;          // specify main and backup server
        $mail->Username = $username ;   // SMTP username
        $mail->Password = $password ;   // SMTP password
+global $log;$log->fatal(array(
+       'SMTPOptions' => $mail->SMTPOptions,
+       'SMTPSecure' => $mail->SMTPSecure,
+       'Host' => $mail->Host = $server,
+       'Username' => $mail->Username = $username,
+       'Password' => $mail->Password = $password,
+$mail->Debugoutput = function($str, $level) { global $log;$log->fatal($str);};


Frequent problems

 Sorry! Attempt to access restricted file

Make sure the webserver user has write permission in the user_privileges directory and that the new user's permission file is correct (it will be user_privileges_##.php and sharing_privileges_##.php).

If that is correct (most probably will be or you wouldn't get to this error) you will have to add some debug message to see exactly what file the application is looking for and can't find. That will be something like this:



Admin Manual
Developer Manual