BackWPup goes crazy with version 3.4.2

Yes, similar behaviour here, although haven’t gone back to v 3.4.1. Using shared hosting with MariaDB.

@independence_day and @volresource we will have a look into this and fix it asap.

I confirm: Weird behaviour with the last version of BackWPUp (3.4.2).

I am working on several websites which perform auto-backups. All the backup names randomly changed since September 28th, which turns out to be a real “mess” when you need to keep/organize multiple backups on a long term.

Besides, when editing a job, the random prefix changes every time you save the job or reload the page.

Thank you for having a quick look at this. This is really annoying.

Best regards,

-Gilles

@all, this is just a cosmetic issue that doesn’t affect the operating of the plugin. However, this will be fixed in the next version, which will be released very soon.

If you’re willing to test out the fix, please contact us at support [at] backwpup.com.

@all,

We just finished the fix today.

But we’d really appreciate if you could test it out. Please download the beta here: https://github.com/inpsyde/backwpup/archive/master.zip

Let us know how it works for you.

Brandon,

I just installed the 3.4.3-beta on a local test server. Unfortunately, it keeps doing weird things.

Initially (with 3.4.1 and below), the backup name was set to:
“backwpup_9d3be602_wpDiviTest_%Y-%m-%d_%H-%i-%s” (9d3be602 being the arbitrary chain the plugin uses to identify the backup files).

When trying to edit a job, the file name is still wrong, changing every time. For example “backwpup_%hash%_8669d9e0363140000_%Y-%m-%d_%H-%i-%s”

I tried to create two more backups, and the file names are still completely random. Here is the list of the last backups with date and time:
2017/10/03 16:22 backwpup_4iyfi7e2p_8669d9e0363140000_2017-10-03_16-22-26.zip
2017/10/03 16:21 backwpup_1gurwlohkx_8669d9e0363140000_2017-10-03_16-21-29.zip
2017/10/03 16:15 backwpup_1e4k57u51e_bcce46c2d7e2d_2017-10-03_16-10-27.zip
2017/10/03 16:00 backwpup_3qw7oi9dt_8669d9e0363140000_2017-10-03_16-00-14.zip
2017/09/25 15:23 backwpup_9d3be602_wpDiviTest_2017-09-25_15-19-16.zip
2017/09/25 15:18 backwpup_9d3be601_wpDiviTest-bdd_2017-09-25_15-18-40.zip
The ones created in September are properly named, the others have silly file names.

I hope this helps.

Best regards,

-Gilles

One more thing, when I try to set the file name of a job as it was before:
backwpup_9d3be602_wpDiviTest_%Y-%m-%d_%H-%i-%s

It becomes:
backwpup_%hash%_wpDiviTest_%Y-%m-%d_%H-%i-%s

@alizesonline
Hi, It’s intended behavior, our plugin will replace %hash% with the real hash string to identify the backup files.
Thank you very much for testing with us ??
If you have any problem about the beta version, please let us know!

Yes, I do have a problem because this hash string changes every time you make a new backup! There is no more consistency in file names.

Besides, having “%hash%” right in the middle of a field that inexperienced users will use to name their files does not seem to me to be a great idea. That is quite confusing. You should change that.

Best regards,

-Gilles

@alizesonline,
you can forget about %hash% string because if the user did not type %hash% in a new backup file name, it’s will be appended automatically.

You should remove the chain “backwpup_%hash%_” from the input field, in my opinion. That is too much confusing for inexperienced users. Let the user enter the final part of the file name (after the hash) and append the appropriate beginning automatically. Just my two cents.

Are you going to fix the %hash% string changing for every backup?

Hi @alizesonline, the new default is no longer backwpup_%hash%_. It’s only because your job already had backwpup_ plus the hash in your archive name.

In the future the %hash% will automatically be placed at the end, but it can be anywhere in the string.

I’m not sure why it is bothering you that the string keeps changing? The string is only ever there for BackWPup to identify it as part of that job. It still does that, just now the string is encoded with some random bytes as well, due to a security issue that was found.

We just wanted to abstract that from the user a bit, and so have the %hash% placeholder, just like there are other placeholders in that string.

I’d like to know that if you don’t like this solution, what do you think is better?

Hi Brandon,

Thank you for your help and fast replies. I do appreciate that.

My concern is about having consistency in file names on a long term, in order to make backups management easy!

You already changed the names of backups earlier this year (by adding the string which identifies the website). Doing so, the plugin stopped deleting old files and we had to do it manually. Not a big deal, except when you have to care of that for many customers’ websites!

Then, when one has many backups on a backup drive, it is really better when file names are consistent and they don’t change twice a year! That helps a lot to identify files, isn’t it.

Whatever the solution you choose to name the backup files, please stick to it. Keep in mind people have been using your plugin for a while and some have a file management strategy that may not be compatible with the changes you make.

Best regards,

-Gilles

Hi @alizesonline,

I understand your concern.

Again the only reason we changed the hashes was because of a security concern that had to be addressed.

And I think with this solution, it’ll actually give you more flexibility to name them however you want.

The naming format prior to 3.4.0 was basically whatever you wanted it to be. We are going back to that, but will append the hash to the end of the filename, where it shouldn’t have any affect whatsoever.

Hopefully that’s agreeable to you.

I did upload another fix to Github because it wasn’t working the way I wanted it to for new jobs. With the newest version, you’ll see that if you create a new job, the default is this:

%Y-%m-%d_%H-%i-%s_%hash%

That first part you can make whatever you want just like prior to 3.4.0.

Hope that makes sense.

@cocreation

I do understand the reasons which brought you to make this update. You are right, it is obvious the new naming will be much more flexible for users.

Do you wish I test the newest version tomorrow (it is time to live office on my side) or is that fine?

Thank you for your help.

Best regards.