idtags:
I installed BACKUP_MYSQL Admin Tool Designed for: Zen Cart v1.3.x and 1.5.x series on my 1.5.5. Zen Cart.
Everything appears is working fine.
But I have 2 questions:
- Admin->Tool menu shows sub menu "DataBase BACKUP_MYSQL" 2 times:
[Attachment no longer available]
- When I use both options **No Compression (Pure SQL) ** and Use GZIP generating backup is compressed in both cases.
Is this issue of installation of web hosting server software?
Any suggestions are appreciated.
I've finally gotten around to again needing to get this to work on a particular host because I have some specific database testing to perform and after a good bit of review and minor modification I came across the above issue (which actually was the problem to begin with).
So here's thing and I'll address the above first:
Starting on line 209 of admin/backup_mysql.php:
switch ($_POST['compress'] && file_exists(DIR_FS_BACKUP . $backup_file)) {
case 'gzip':
@exec(LOCAL_EXE_GZIP . ' ' . DIR_FS_BACKUP . $backup_file);
if (file_exists(DIR_FS_BACKUP . $backup_file)) @exec('gzip ' . DIR_FS_BACKUP . $backup_file);
break;
case 'zip':
@exec(LOCAL_EXE_ZIP . ' -j ' . DIR_FS_BACKUP . $backup_file . '.zip ' . DIR_FS_BACKUP . $backup_file);
if (file_exists(DIR_FS_BACKUP . $backup_file) && file_exists(DIR_FS_BACKUP . $backup_file . 'zip')) unlink(DIR_FS_BACKUP . $backup_file);
}
The test to the right of the word switch: $_POST['compress'] && file_exists(DIR_FS_BACKUP . $backup_file) Well... by checking the radio button for "NOT" compressing (or to compress) well that results in the post to contain some text (even if it is the word no) and then that is && with the existence of the file which should basically be true at least when submitted through the admin screen interface. Well, the post of text that is not false && with a true condition evaluates to true. Then case 'gzip' is evaluated against a statement of true and since gzip isn't false or NULL it evaluates as true and the code within the case 'gzip' area is executed. During that execution (which is how I found the solution to my problems) the gzip function is attempted any number of ways. First by use of the software as identified in LOCAL_EXE_GZIP (defined in admin/includes/init_includes/init_gzip.php) and then basically if that doesn't work directly by use of gzip. What this also means though is that the 'zip' code never gets executed...
So I made the following changes in this area:
switch ($_POST['compress'] [B]. ([/B]file_exists(DIR_FS_BACKUP . $backup_file)[B] ? 'true' : '')[/B]) {
[B]case 'notrue':
break;[/B]
case 'gzip[B]true[/B]':
@exec(LOCAL_EXE_GZIP . ' ' . DIR_FS_BACKUP . $backup_file);
if (file_exists(DIR_FS_BACKUP . $backup_file)) @exec('gzip ' . DIR_FS_BACKUP . $backup_file);
break;
case 'zip[B]true[/B]':
@exec(LOCAL_EXE_ZIP . ' -j ' . DIR_FS_BACKUP . $backup_file . '.zip ' . DIR_FS_BACKUP . $backup_file);
if (file_exists(DIR_FS_BACKUP . $backup_file) && file_exists(DIR_FS_BACKUP . $backup_file . 'zip')) unlink(DIR_FS_BACKUP . $backup_file);
}
But... There's something about it all... There is just enough functionality in here to support a compressed backup, which could unfortunately also not be decompressed if several things do not line up correctly. I later found that I had to either modify the setting for LOCAL_EXE_GUNZIP to just be gunzip instead of some file path or modify the command for unzipping so that it referenced gunzip directly rather than with LOCAL_EXE_GUNZIP... Problem being that the decompressed file would get generated but have no content in it and because it exists that there was an attempt to restore the "nothing" which "succeeded" though made no changes.
Anyways, had the above "mistake" not existed, then I wouldn't have known that the system supported gzip (install seemed to indicate that it didn't exist, but when running the backup of this site, a file was successfully gziped even when the request was to not do so... Ie. a whole mess of confusion, but finally sorted out... Now though, if nothing else is done to attempt to override the compression, every backup would be non-compressed and still would not know that the system supported compression... Little bit of a round robin, no? Obviously a little additional checking here or there might make it easier/faster to resolve, but...
The above may or may not help someone, I don't really suggest making the changes in the base code without first incorporating some sort of additional testing/checking that gzip isn't an available option. I can safely make the above change(s) the the plugin's file, identify to the plugin to override compression, and modify the path to the compression/decompression programs and now have the option to export compressed or not, and can restore either a compressed or non-compressed file.
Total changes:
Above code changes.
in: admin/includes/extra_datafiles/backup_mysql.php
changed:
define('COMPRESS_OVERRIDE',false);
//define('COMPRESS_OVERRIDE',true);
to:
//define('COMPRESS_OVERRIDE',false);
define('COMPRESS_OVERRIDE',true);
in admin/includes/init_includes/init_gzip.php
changed:
define('LOCAL_EXE_GZIP', '/usr/bin/gzip');
define('LOCAL_EXE_GUNZIP', '/usr/bin/gunzip');
define('LOCAL_EXE_ZIP', '/usr/local/bin/zip');
define('LOCAL_EXE_UNZIP', '/usr/local/bin/unzip');
to:
define('LOCAL_EXE_GZIP', 'gzip');
define('LOCAL_EXE_GUNZIP', 'gunzip');
define('LOCAL_EXE_ZIP', 'zip');
define('LOCAL_EXE_UNZIP', 'unzip');
though the changes made above won't really make the zip option available for selection. That requires some other modifications for that option to be displayed.
