softwaredancer

Hi Brad,

You are absolutely correct in your suspicion that my problem was a failure to clear the cache after installing the patch.

When I did that, the patch worked just fine.

My compliments on addressing this issue so quickly and effectively. Total Upkeep is a great plugin, and your work in supporting it is most impressive.

Best,
softwaredancer

I disagree. The free version of UpdraftPlus will not backup .htaccess or any of the core WordPress files. If you need to do a rollback for a core upgrade, you’ll need to retrieve these files from www.ads-software.com and do a manual restore.

I regard this as a critical flaw. It bothers me that full backups are available only with the paid version of the plugin, and that the limitation in the free version is not disclosed more prominently.

I think a lot of people using UpdraftPlus are not aware of the problem. They’re creating what they think are full backups of their site, and will only discover the backups are incomplete when they try to do a restore for a core upgrade or migrate their site.

Hi Jesse,

That WP Rollback plugin is very cool. Thank you for introducing me to it.

Following your instructions, I tested the patch from ‘branch.issue-445.202102111509’. I noticed that a lot of work has been done on the javascript file (wp-content\plugins\boldgrid-backup\admin\js\boldgrid-backup-admin-backup-now.js).

Unfortunately, the problem remains. When you run a backup from the ‘Settings’ tab, the program still does not write the ‘table_inclusion_type’ variable, and in consequence the database dump file is not included in the backup.

Thanks for all your good work in nailing this down, and for the bug report you filed, which looks just fine.

When first I stumbled upon this problem, I had thought it was specific to my xampp installation. I also have the plugin installed in an site hosted by GoDaddy, and at that time the plugin appeared to be working correctly there.

However, now that I understand that the problem is triggered by pressing the ‘Backup Site Now’ button from the Settings Pane, I was able to replicate the bug on my GoDaddy installation. So the problem is not specific to xampp. And I want to make that clear, here in this forum.

Obviously, the workaround is to press the ‘Backup Site Now’ from any pane other than the Settings Pane. I’ve tested it from all the other panes, and the backup always works just fine.

Hi Jesse,

Thank you for your response. I’m more than happy to help.

I did some further testing of the plugin. When you call up the plugin from the admin page of WordPress, you are presented with a page featuring many tabs: Dashboard, Backups, Transfers, Tools, Settings, Preflight Check, Support and Premium Features. Regardless of which tab you are on, you see the ‘Backup Site Now’ button presented near the top of the page.

It turns out that the backup works properly when you are on any tab other than the ‘Settings’ tab. But when you are on the ‘Settings’ tab and press the ‘Backup Site Now’ button, the backup file it creates will not include your database backup file. When you are on the ‘Settings’ tab, the URL displayed in the browser is ‘[domain]/wp-admin/admin.php?page=boldgrid-backup-settings’. In other words, the referring page is ‘boldgrid-backup-settings’.

I followed the instructions on your video, and it appears to me that if when the ‘Backup Site Now’ button is pressed from the Settings tab, the javascript program fails to write the ‘table_inclusion_type’ variable. But when you press ‘Backup Site Now’ from any other tab, this variable is written.

I ran 5 trials:
Trial From Dashboard Tab, Full Backup. Outcome: Works as expected
Trial From Dashboard Tab, Custom Backup. Outcome: Works as expected
Trial From Settings Tab, Full Backup. Outcome: failed to include DB file in backup file
Trial From Settings Tab, Custom Backup (specify all tables). Outcome: failed to include DB file
Trial From Settings Tab, Custom Backup (specify all but one table). Outcome: failed to include DB file

The full contents of the form data from these trials are pasted here:
https://pastebin.com/M1bFpjaW

If there is anything else I can do to help, I’ll be more than happy to to do that.

Best,
softwaredancer

I traced the problem to function get_from_post() in file boldgrid-backup\admin\class-boldgrid-backup-admin-db-omit.php.

This function queries $_POST[‘include_tables’] for a set of tables to be included in the backup, and determines what to exclude as all tables except those to be included.

The problem in my installation is that the $_POST[‘include_tables’] returns an empty array, and so all tables are excluded.

The brute force solution is to insert the following line
$exclude_tables = array();
directly above:
return $exclude_tables;
in this function.

This fixes the problem by returning an empty array for the list of tables to be excluded. A complete database backup is then included in the backup file.

But a real fix of the problem will have to look at why $_POST[‘include_tables’] returns an empty array. It appears to me that a javascript program
(boldgrid-backup\admin\js\boldgrid-backup-admin-backup-now.js) is run when the user presses the ‘backup now’ button, and this program is responsible for populating the _POST supervariable with an array of tables to be included. That javascript program is where the program fails, but I lack the javascript expertise to determine what the problem is.

However, it seems like this bug is worth fixing. When the backup fails, it does so silently; there is no error message – other than a note in the log file that no database tables were backed up. I suspect a lot of people are creating backups not realizing that that a database backup is not included with a backup of their files.