Backup userspice files & table

Furthermore to this, how about if backup all is the selected type (similar to how single table you select the table), we can check all checkboxes, but not list the backup folder, and then we define the backupItems instead of the system deciding? Think it might fix it?

Don't know if this is a solution or not...but moving the backup folder outside of my root directory fixed my issues and no longer backs up the backup folder...so my destination is ../backups/

@Firestorm...yeah... I get that...my problem is that I build most of my apps in at mydomain.com with login being at mydomain.com/users/login.php

The good thing, like I said, is that I can get by with basically backing up /uploads and my db. I don't even really need to back everything up through the built in backup system. On the other hand, with index.php being in root, I wouldn't be surprised if the bulk of people don't put their application there. The thought was that they would have a clean root directory with userspice out of the way.

@Brandin - The only issue with that would be server permission issues. You would have to put the backup folder BELOW root to hide it using that method. We can't assume that we'll have that permission on the server. We already know we have write permission in the root folder or we wouldn't have been able to make the init.php file during the install process.

True...well that is my temporary solution! I will see what I can crack while I code on my next few days off and if I come up with something I'll let y'all know!

Sounds good @Brandin.

@Firestorm...prayers are with your family. Thanks for all you're doing.

Thanks @mudmin means a lot,

i think I've solved the backup saving back issue, in admin_backup.php around line 78 replace:

$backup_dest = .$settings->backup_dest;

with:

$backup_dest = ".".$settings->backup_dest;

what I've done is prepend a DOT to the directory name so that recurse_copy() thinks its a file so then recurse_copy will basically not recognise its file type and ignore it,

we now need to apply the fix to the

$allBackupFiles

variable around line 362 so we have the right path to display the back ups.

I've only tested on localhost on mac which works as it should and doesn't hide the directory and i believe windows wouldn't either.

EDIT: scrap that lol, only worked because MacOS had hidden file, back to drawing board

I'm looking at shortening the filename as @Brandin reported so i may strip sha1 and replace with something more adaptable, i would use random_str() but its only php7 > and a polyfill has to be used for php5 > which seems a bit over the top for filenaming, maybe just strip sha1 leaving timestamp. i can't see many people wanting more than a few backups but i could be wrong

haha. You got me excited with that fix.

I was expecting to see an array of actual files being built somewhere in there, but I couldn't find one. My initial thought was to make the temp directory and the zip file begin with USBackup or something like that and then just tell the app to ignore anything that began with usbackup.

ha ha shame its not april lol

well looks like I've fixed it, on localhost at least, haven't tested remote.ive prefixed the backup directory name with @ and then in backup_util.php extended the RecursiveFilterIterator class with a filter excluding @.

I've updated the gist with your inclusion of everywhere and my fix, you'll only need to replace admin_backup.php and backup_utils.php

backup the old one first, just in case.

oh make sure to add @ to the backup folder if you have an existing one i.e: @backups/

fingers crossed

https://gist.github.com/Firestorm-Graphics/23862bf5a7111aea675ab748cb0e01d8

Will try this now to see if I can get it to work on cP.

I'm thinking the error about file name length was only due to it backing up the backup folder which we are trying to solve, because as soon as I stopped backing up that folder the error was gone...will let you know my result of this.

Unfortunately, if I followed your steps right...not working on this end... :(

@Brandin yeh i get gateway timeout on remote which i got originally on mudmins mod, so defo infinite loop on backups, looks like it will have to be dealt with on either the recurse_copy() function or the backupObjects() function as its happening before copying & zipping up. files and directories are held in array as $backupItems

Ive CRACKED it ! i THINK ? lol

right, I've edited the gist, mainly backup_util.php and admin_backup.php, I've tested on localhost (mamp pro) and remote shared linux & cpanel server all working perfect and quicker than expected.

https://gist.github.com/Firestorm-Graphics/23862bf5a7111aea675ab748cb0e01d8

just replace as is

I don't know what you did...but you did it. THANK YOU! This is awesome!!!

awesome thats great news , after jumping in deep i really didn't have to do much, prepending the folder with @ turned out not to be necessary but i left as is, i changed a few lines in the recurse_copy() function in backup_util.php.

added:

line 65 ish:

global $settings;

line 66 ish:

$dest = '@'.rtrim($settings->backup_dest, '/');

added permissions to @mkdir

then changed:

line 70:

if (( $file != '.' ) && ( $file != '..')) {

to:

if (( $file != '.' ) && ( $file != '..') && ($file != $dest)) {

thats it really, now for backup restore, do we do as backup script reverse engineered or do we just restore tables ?

That's a whole other playground... ;)

That is very good news. I'll be rolling this in. THANK YOU!

This is rolled out to 4.2.10 and 4.3 Thanks for this. I'm definitely interested in restore. I think it will be pretty tricky though.

awesome, yeh I've put restore on back burner until ive finished database driven menu's and done extensions, any other changes in the latest update ?