Total Upkeep Backup is not backing up the database in an xampp installation

@softwaredancer You posted email addresses in that log dump, don’t do that. Also please do not post large code or responses like that here, it doesn’t work after ~10 lines or so.

If you need share that data please use https://gist.github.com/ or https://pastebin.com/ instead and post the link to that paste.

Hi @softwaredancer

Thanks for reaching out! I’m sorry to hear about the trouble backing up your local database.

Something odd is definitely going on, since you mentioned that you have Back up all tables selected, but all of your tables are listed as excluded in this log:
[2021-02-08 00:16:18 UTC] No database tables selected to backup. A database export will not be in this backup.
Can you double-check that all the database tables are selected?

I tested the plugin on XAMPP (although I’m running XAMPP for Linux, not Windows) and it did work for me as expected.

One thing I might speculate is that your MySQL (MariaDB) user may not have full permissions to your database. One way to test this would be on the command line, using the same credentials from your (local) wp-config.php file:

mysql -u (DB_USER) -p(DB_PASSWORD)
shell> mysqldump --databases (DB_NAME) > test_dump.sql

Another possibility I might recommend is LocalWP which is a very user-friendly local WordPress environment that “just works.”

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.

Hi @softwaredancer

Thanks for the response, that’s an absolutely awesome amount of work you did to get that information for us.

We’re looking to try and replicate this issue, so there’s a couple things I’d like to ask you for.

First, can you describe exactly the steps you’re taking when this issue occurs? For example, what page are you on when you initiate the backup, and what exactly you’re using in the “Backup Site Now” form.

Depending on your settings, we wouldn’t expect the include_tables array to be populated if you’ve selected “Backup all tables” radio button. I took a minute to record a short video showing you how to inspect the submitted form data in your browser’s dev tools.

If you have a few minutes, would you mind watching this and letting us know what form data you’re seeing when you create your backup?

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

Hi @softwaredancer

Thank you very much for the detailed troubleshooting information! I really appreciate how much help you’ve been willing to offer with this bug.

We’ve been able to replicate the bug now, and I’ve filed a bug report on our GitHub repository.

Stand by for an update to the plugin to resolve this for you, and I’ll post an update here when it’s released.

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 @softwaredancer

Yes, I’ll admit the XAMPP “red herring” threw me off at first too, but I was also able to replicate it in other environments, as long as I was on the “Settings” tab.

You’re right that other pages and tabs work for manual backups, and this issue doesn’t affect scheduled backups either.

Hi @softwaredancer

We have a patch for this bug available in a testing branch of the plugin. If you’d like to give it a shot, here’s how you can do it.

First, install and activate the WP Rollback Plugin, which lets you switch versions of plugins. Then, navigate to Plugins > All Plugins, and locate the rollback link next to Total Upkeep.

From here, look for the branch.issue-445.202102111509 branch (very near the bottom of the list) and click Rollback.

Here’s a quick video on using WP Rollback to try out a testing branch (this video was from another patch, make sure you use branch.issue-445.202102111509):

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.

Hi @softwaredancer, thanks for taking some time to test the new branch, and I’m sorry it wasn’t working right away for you.

As you stated, the new changes are in javascript. Are you able to clear your cache and test again? I’m pretty sure the new changes should resolve the issue, we just need to make sure the new javascript is being loaded and not the old. IE When you go to yourdomain.com/wp-content\plugins\boldgrid-backup\admin\js\boldgrid-backup-admin-backup-now.js you should see the new js.

The way I tested is that I installed the patch version in a free WordPress testing environment. If you click this link and then click “try it” (no need to sign up), it’ll install a new WordPress site with the branch.issue-445.202102111509 branch of the backup plugin installed. From there, I created a backup on the settings page, and my database was backed up.

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

Hi @softwaredancer –

This patch has now been included in the 1.14.11 release, so you can now update to the current version of the plugin.

Thanks so much for discovering this bug and helping us get it fixed! Please let us know if you have any other issues or questions, we’re happy to help.