[Plugin: BackWPup] Error after activating plugin

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.

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.

contribute is allowed with the wordpress svn. i can add you to do this.

for the sql table creation and update i use a WordPress function. IN my test it works fine.

hopfuly fixed the if statements and the <? tage in the def. version but it isn’t tested

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?

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.

the error in the sql statemant did i Fixed in the dev. version.

the code i will implemt in the log view.

i have added a quick and dirty patch for the time out in the dev version.
please test it…..

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.

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

it’s for not apache webservers because only apache can handel .htaccsses files. it gifs a littel bitt mor security that hopfully no one cann accssess the folder with a webbrowser and browse the directory.
on apache webserver the index.html is not needed.

I will look to check if it a apache webserver an then dont create the index.html.

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 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.

Either it hangs, or it’s killed. Are you sure you don’t have a memory limit on your host?

Also, I’ve heard a lot of reasons why Windows servers aren’t a good idea, and none to do with malware; they just work differently and don’t have all the utilities that Web programmers are used to having on *nix-like systems.