vTiger 5.4.0 enable backup quirk

I use the vTiger CRM product and it has a unusual quirk with enabling backups. Whilst the user interface (CRM settings -> Backup server) has check boxes to enable local and FTP backup the script actually tries to alter the following file, /user_privileges/enable_backup.php and in that set the two flags to a value of either true or false,

$enable_local_backup = 'true';

$enable_ftp_backup = 'false';

As the script has no permissions to do that then it gets a fopen() permission error (Warning: fopen(/*****/user_privileges/enable_backup.php): failed to open stream: Permission denied in /****/modules/Settings/SaveEnableBackup.php on line 43) and so when the ajax refreshes the screen it looks as if nothing has been done.

Without messing with your directory permissions then you can edit the /user_privileges/enable_backup.php manually.

Even if you manage to get the directory details into the local backup it will not work unless that enable local backup flag is set to true. It will say that it has done a backup but it will not save any file.

PHP Warning: Invalid argument supplied for foreach()

If you get a Warning: Invalid argument supplied for foreach() but the code looks and seems to work fine then the issue is that foreach() needs an array but you are passing a Boolean due to an error in a previous function.

You will see this problem where you have something that is returning an array or false e.g. glob() and then you pass the returned value to the foreach() without checking if the variable isn’t false. e.g. in this case glob() can return false if it can’t see the path,

        foreach( $paths as $path ) {
            $filenames = glob( $path['path'] );
            if ( $filenames != false ) {
                foreach( $filenames as $filename )

In that example if glob() failed on one of the paths then it would return false. In my example above I check that $filenames is not false before I use it with foreach(). You can also use is_array() as well. To confirm your theory on your code you can add in var_dump() before the foreach() on the variable that you pass to confirm the type of the variable of what you use in foreach().

 

Using error_log() with print_r() to gracefully debug PHP

When debugging php code (especially Open Source code you have not written yourself) then to get a feeling of what is passed around when it doesn’t work I find that the print_r() function is very useful.

Trouble is that if you just throw in print_r() into the code where you think it is faulty then you can upset json, AJAX or your web page layouts as the print_r() splatters stuff to your displayed web page or in some cases the PHP file is not going to a browser (e.g. the PayPal IPN notify).

The trick is to throw it at the error log as follows e.g. if I was tracing what $number was being set to then I would use….

error_log(print_r($number,true));

note that you MUST set that print_r() option to “true” so that it returns a string. This string is then sent to the error_log() function which formats it with referrer details and puts it into the Apache error log.

Where does it end up ? Well on my test system on a non-vHost it is /var/log/apache2/error.log and on a vHosted server it is :/var/www/vhosts/<domain name>/statistics/logs/error_log so on your own system it will be a similar Apache error log file. Just tail that file to see what the messages are which will be something like this (in this example the $number was “2008” so the output for that error log message was,

[Sun Jan 01 13:21:12 2012] [error] [client 192.168.2.2] 2008, referer: http://19
2.168.2.250/bluebox/index.php/numbermanager/index

To synchronize the log messages with your testing then just look at the logging time.