carlosman

I think we both may be having the same problem. Mine shows up in a Windows 2008 Web Server, using PHP5 with FastCGI. My related post is here. Please, have a look. We may be able to help each other with testing for a solution. I think this could very well be, as you suggest, a memory exhaustion problem. That would be, I think, easier to solve than fixing/getting PclZip fixed.

Just an update, in case you are still looking. On the issue with the Windows 2008 Web Server installation, I dedicated a little more time to debugging the problem (I am using your development version 0.7.3). I found the line causing it, but I think the problem is outside the scope of BackWPUp’s realm. The line is located in the file.php script, in the wp-content/plugins/backwpup/app/dojob directory. The line is number is 97 and reads as follows:

if (0==$zipbackupfile -> create($filelist,PCLZIP_OPT_REMOVE_PATH,str_replace('\\','/',ABSPATH),PCLZIP_OPT_ADD_TEMP_FILE_ON)) {

The problem is the PclZip->create method. It hangs, without returning an error code to your “if” statement, so program execution stops right there. It does not hang on a particular file from the list, because the Zip files it generates end up having different sizes for the same backup set. This must be a bug within PclZip. It may be related to the file naming structure in the $filelist variable, but I doubt it. I will continue investigating the matter.

I installed the development version of your plugin on a Windows 2008 Web Server and it fails. It gives me a “500” error. I am assuming it is a problem with missing PHP modules in the installation. Could you tell me which specific PHP modules your plugin needs? I noticed the server was lacking the ZIP module, and activated it. Then the first errors disappeared, but this new 500 – Internal Server error showed up.

Any help would be appreciated.

Just out of curiosity, why does the plugin write an index.html file on the wp-content/backwpup directory?

So far, so good. Thanks a lot. I will continue testing the other plugin features.

Just so you know, I tested this setup on a Windows 2000 Advanced Server, using PHP with FastCGI, and the Ionics ISAPI URL Rewriter.

Everything works like a charm. Given the notorious resistance Windows presents to some “specialized” plugins, I have to congratulate you on a job well done.

I also had to change options-view_log.php in order to accommodate for the very long logs produced by my 367MB backup. I patched the code to set the script time limit to “maxexecutiontime”, with all the same safeguards used in “bevore.php”.

I know the “maxexecutiontime” parameter is not the ideal timeout for log listing, but it was a quick patch to prove the concept. The sanest alternative for log listing timeouts would probably be a percentage of the “maxexecutiontime” parameter. Something like:

<?PHP
if (!ini_get('safe_mode') or strtolower(ini_get('safe_mode'))=='off' or ini_get('safe_mode')=='0') {
	if (empty($cfg['maxexecutiontime']))
		$cfg['maxexecutiontime']=300;
} else {
	$cfg['maxexecutiontime']=ini_get('max_execution_time');
}
if (intval($cfg['maxexecutiontime']/4) <= 300) {
	set_time_limit($cfg['maxexecutiontime']);
} else {
	set_time_limit(intval($cfg['maxexecutiontime']/4));
}

$log=explode("\n",$wpdb->get_var("SELECT log FROM ".$wpdb->backwpup_logs." WHERE logtime=".$logtime));

?>

In this case, I am shooting for 25% of the “extended” script runtime for backups. That divisor (4) could also become a parameter in the DB, but that may be overkill for some users. In my case, I manage a lot of blogs which range from the smallest sizes to gigabytes. If I can adjust these two timeouts at will, on a per-blog basis, I have got the ideal backup plugin.

I found the error to be this portion of the SQL statement:

log LONGTEXT NOT NULL default '',

which should read (according to the MySQL 5.0+ documentation):

log LONGTEXT NOT NULL,

since LONGTEXT fields cannot have default values.

What version of MySQL are you using?

There is, at least, one option you should include in your settings screen. It is the “maxexecutiontime” option.

You set it for 300 as a default (since the first time it is NULL in the “wp_options” record for BackWPup. It is not enough time for backing up a site I manage, which is heavy on graphics.

I changed it in the database, but an interface for it seems like a good choice, since there is a high probability of other bloggers having this issue.

Your plugin could become a lifesaver for MANY bloggers. I am betting on it!

P.D.: The option is actually in the settings page, but the code had some issues (“<?” tags instead of “<?php” and some “if” statements that were not working, so defaults could not be changed).

I can contribute patches if it is at all allowed. Just let me know how.

I just manually created the table in the MySQL database, using the following script (which worked for my setup):

CREATE TABLE
wp_backwpup_logs
(
logtime BIGINT NOT NULL,
jobid INT NOT NULL,
jobname VARCHAR(255) NOT NULL,
type VARCHAR(20) NOT NULL,
error TINYINT NOT NULL default ‘0’,
warning TINYINT NOT NULL default ‘0’,
worktime TINYINT NOT NULL default ‘0’,
log LONGTEXT NOT NULL,
backupfile VARCHAR(255),
PRIMARY KEY (logtime)
)
DEFAULT CHARACTER SET utf8;

Maybe this change can be included in a future version. Thanks a lot. I really like your plugin.