Jesse Owens

Hello Benjamin-

Thanks for the report! A database connection error is a very big deal, so we definitely want to find out what’s causing that.

Other than the things you’ve already checked (i.e. Credentials, Repairing the Database), I’m not aware of anything in the plugin itself that might cause this error just from being active.

I can imagine in some situations that you might get an error while a backup is actually running. Total Upkeep temporarily “pauses” the database while it’s backing up to prevent any changes during that period, which could cause data corruption. Typically, this pause is extremely brief (less than one second), but if your database is very large, or if it’s on a remote server with a slower connection, I could imagine this might take “3 or 4 times” to reload. To avoid this, we recommend scheduling your backups for a “slow” time-of-day for your traffic, such as late night or early morning.

Can you confirm if this is happening while Total Upkeep is just active, or if it’s happening when a backup is being created?

May I ask what type of hosting you’re using? If you’re on a VPS, you might be able to get more information from the MySQL error logs, or if you’re on a shared plan, your host may be able to check for you.

Is your MySQL server running on localhost, or a remote server? Is there anything “special” about your database setup?

Hello @brucetm –

Thanks for the report, that’s one we haven’t seen before.

Do you mind sharing what browser and operating system you were using when you saw this behavior?

The “lightbox” library we use is called ThickBox, and it’s built into WordPress Core. Typically, the scroll bar dynamically grows and shrinks when the Custom options are expanded, but it sounds like that’s not the case for you.

One thing you can do is set up your “regular” backup settings, in the Total Upkeep > Settings > Backup Storage menu. This will be on its own panel, and the settings will apply to the “Backup Site Now” pop-up even if you can’t scroll to see them.

Can you confirm if the same issue happens for you on another browser?

Hello @izziebot –

Thanks for reaching out, I’m sorry to hear that your backups aren’t working.

The first thing to check is the log for your most recent failed backup. You can find the log in Total Upkeep > Tools > Logs. Look for a log with a name like archive-XXXXXXX.log with a timestamp matching your last attempt.

If you can paste that information here we can take a closer look at what might be going wrong for you. The log may contain your server username and website address, so be sure to remove them before pasting if you prefer to keep those private, or alternatively you can file a private premium support ticket in your BoldGrid Central Account.

Your log file will be the best way to identify what might be going wrong.

You mentioned that you’re trying to transfer from a staging site. Is that a DreamHost staging site, or are you using BoldGrid Cloud WordPress? If you’re using a DreamHost staging site, you can also use their built-in publishing tool to skip the backup process altogether.

We also have some additional troubleshooting information in this guide.

Hi @swissschokolade

It’s been a little over a week since we heard back from you, and it looks like you were able to successfully migrate your Crio website over to your main domain.

If you’re all set, can you mark this thread as “Resolved?” If you have any more questions, please let us know, we’re happy to help.

Hi @pinecones

It’s been a little over a week since we heard back from you, so I’m marking this thread as resolved.

Please let us know if you’re still having trouble, we’re happy to help.

Hi @goodvibesonlyb

Thanks for the screenshots, that’s very helpful!

It looks like the two main issues you’re seeing here are swapping your fonts to avoid a Flash of Invisible Text (FOIT), and eliminating render-blocking CSS.

I noticed from looking at your site that you’re using the Hummingbird plugin for performance. You can use Hummingbird to eliminate the render-blocking CSS files (from the second screenshot). Here’s their documentation on how to do this.

Swapping the fonts may be trickier, and the Support team at Volthemes may be able to provide better guidance than we can. Since that’s a commercial theme, I can’t try it out or see the code to give you exact instructions. I did check their documentation on Fonts, and I didn’t see an option to enable swapping the font.

As for the two errors from Post and Page Builder, you can safely ignore those. You can see in the error message that they are (Suppressed), which means we expect to see some warnings running the XML parser.

Hello @goodvibesonlyb –

Thanks for the question, I’m sorry to hear about the errors you’re seeing.

The error messages you have listed here are related to PHP’s XML parsing library not recognizing the HTML5 tags for <article> and <section>. Both of these tags are common in WordPress themes, and are valid HTML5 markup, but PHP uses a stricter XML parsing library.

The Post and Page Builder itself doesn’t actually use these tags unless you’ve manually entered them into your post content, those are normally tags that are a part of the theme itself.

All that being said, these are only warnings and shouldn’t actually be causing any noticeable problems for you. Can you describe the issues you’re experiencing, and the steps you take to get to the problem?

Hi @pinecones

Thanks for the additional info!

It’s good to know that you have cPanel, that should help us to troubleshoot.

Using the cPanel File Manager, double-check that the plugin files are actually deleted by looking in wp-content/plugins/ for the folder boldgrid-backup. That folder should not exist if it was deleted successfully.

Using the Cron Jobs tool, look for any jobs that have boldgrid_backup in them, and if you see those go ahead and delete them.

Finally, double check the Domains and Sub-Domains menus to make sure that there’s not another WordPress site there.

Hello @swissschokolade

Thanks for the question! We’ll be happy to help to deploy your cloud site to your main website.

First, just so you know what’s going on, it looks like you created your Crio Website on our Cloud WordPress staging platform, a premium service that you get for free through your DreamHost subscription, but it is entirely separate from your actual hosting account and your website.

To transfer your Cloud site to your production website, use these instructions to use the Total Upkeep plugin to create a backup of your cloud site and migrate it to your main site.

Essentially, the process consists of:

1. Create a backup of your Cloud site
2. Copy the transfer link for your backup
3. Log into your website at DreamHost
4. Install Total Upkeep there (if it’s not already installed)
5. Use the Total Upkeep – Transfers Menu to download your backup from the cloud site
6. Finally, restore the backup to make the site live.

Important Note! When you created your cloud site, you most likely had a random Username and Password created for your user. Make sure you update your password before you create your backup so that you can log in once you restore it to your main website. You can do this in the Users – All Users – Edit menu of your cloud site.

Hi @pinecones

I’ve replied to your thread in the Total Upkeep Support Forums, hopefully we can get you fixed up.

Hello @pinecones –

Thanks for the question, I can see how these constant backups taking down your server are a big problem.

It sounds like there’s two major issues to tackle- first, that the backups are happening all the time off-schedule, and second that they are still happening even after you’ve deleted the plugin.

For the second problem, it shouldn’t be possible at all for the plugin to continue making backups if you’ve already deactivated and deleted it. Are there any other websites on your server that might still be running the plugin? Perhaps a staging or development site?

I can imagine a situation where you’ve deleted the plugin, but the system’s Cron jobs weren’t deleted. Your web host may have a tool to configure Cron jobs, or you can use the crontab -e command using SSH to double-check. Even then, however, the plugin couldn’t possibly make backups if it had been deactivated, much less so if it was actually deleted.

For the issue of the unexpected backups, the most common cause of that is having the plugin configured to automatically back up the website before plugin and theme updates.

We have a troubleshooting article that goes over finding out what triggered an unexpected backup and how to configure backups before automatic updates.

Of course, neither of those help until we find out how the backups are still happening with the plugin deactivated. The only possibility I can think of for that is that there is another website on the server that’s still running the plugin.

Hi @aethon

We haven’t heard back from you in about 2 weeks, so I’m marking this issue as resolved. However, please let us know if you’re still having any trouble, we’re happy to help!

Hi @jefffreemanpresents

Thanks for the feedback! I’m sorry to hear that the progress bar is both nagging and stuck, I agree that would be really annoying when you’re trying to work on your site.

It sounds like there are two different technical issues that are occurring at the same time- first, that a backup is running whenever you log into your site, and second that it doesn’t get past 14%.

The first issue is likely because the option to backup your site before automatic upgrades is enabled using the wp-cron system, which would cause a backup to run whenever you log in. You can disable this in the Total Upkeep > Settings > Auto Updates menu.

The second issue, that the backup isn’t completing, likely means some error was encountered during the backup process. We have a guide detailing a few common causes and fixes.

We also have an update coming soon for Total Upkeep that has better detection of a failed backup that will both remove the stuck progress bar from your admin pages, as well as help you identify and fix failed backups.

Thanks again for the feedback, we appreciate any feedback, good or bad, and if you’d like any more help troubleshooting please let us know in the Support Forum, we’ll be happy to help.

Hi @q3dm0

The < p > tags and & nbsp characters are added during the TinyMCE init with a filter called wpautop.

Try adding this to your filter:

$init['wpautop'] = false;

Hi @aethon

Thanks for the great question! Normally we don’t provide support for Premium features here in the www.ads-software.com forums (we can support the premium product on our dedicated support forums).

However, backups before auto-updates is also a feature in the Free plugin hosted here, so I’ll go ahead and answer here in case anyone else has a similar question.

Since auto-updates are run on a WordPress core wp-cron schedule of “Twice Daily,” these are different than the normal scheduled backups that you can specify the time-of-day for.

However, I think this is a useful feature, so I’ve gone ahead and created a feature request for our developers based on your feedback.

In the meantime, you could accomplish this with a third-party plugin like WP Crontrol or Advanced Cron Manager.

You can use these plugins to alter the events wp_update_plugins and wp_update_themes to change their schedule from “Twice Daily” to a set time-of-day. You’ll want to couple that with an automated uptime monitor like Pingdom, Newrelic or something similar (many CDN’s come with an uptime monitor as well). This will ensure that wp-cron is triggered to run at the correct time during your slow time of day.