Joseph W

Hi Mike,

At this point I think you are correct, there is potentially some kind of issue with the server environment that is responsible for these errors.

The only other instance that I have seen with WP-Cron scheduled backups not triggering involved a caching plugin with Object Caching enabled. However in that situation all WP-Cron jobs were failing to run, not just ones related to Total Upkeep.

Please let us know if you host finds anything so we can continue exploring other options!

Hi webed9,

If you are looking for some ways to improve your website’s SEO then I recommend checking out the WordPress SEO guide from Yoast to get some helpful tips. They are one of the industry leaders in WordPress SEO and there should be some helpful information in there on how to attract more visitors and get better analytics results.

They also have an article linked in that guide on Improving Site Speed that recommends a few caching plugins to use for that. Our caching plugin, W3 Total Cache, is listed in there and we have a configuration guide that should help you get the most out of it.

The theme Customizer should have some device preview options that allow you to see what your website will look like at various screen sizes. There are a few device icons located towards the bottom of the Customizer options on the left side that allow you to change the Customizer view size.

Please let us know if you have any other questions for us!

Hi Mike,

Those settings don’t raise any particular red flags with regards to WP Cron scheduled backups and they are consistent with setups where system level Cron jobs are disabled. Did your host have any additional information about WP-Crons that might help us figure out what the problem is?

Hi Mike,

I think the next step to figuring out what is going on will be to contact your hosting provider to see if they have any insight on what might be preventing the Cron from executing as expected.

Another thing you can try if you haven’t already done so is to delete and reinstall Total Upkeep completely. It is possible that there is some kind of file corruption with the Cron scripts generated by Total Upkeep and a reinstallation could help ensure the integrity of all the files.

Hi Mike,

Out of curiosity, are any of the cron jobs that work on your website created by third plugins or are they all core WordPress crons?

Hi Mike,

I’ll circle back with Brad on this and see what else we can think of that might explain why the scheduled backups aren’t firing off as expected. It might take us some time to figure something out and thank you for your patience throughout this whole process!

Hi David,

If you can, try fully purging the cache from W3TC and check the settings to make sure that Page Caching and Minify are disabled for logged-in users.

It could be that somehow the JS minification process malfunctioned after the restore and is creating those jQuery errors.

Hi Mike!

Well at least the run_jobs cron isn’t disappearing any more so it sounds like we’re making some progress.

Which cron event did you try the Run Now option on? Was it boldgrid_backup_wp_cron_run_jobs, boldgrid_backup_wp_cron_backup, or both?

Are the Total Upkeep cron jobs the only ones that aren’t triggering or are there other crons that are overdue?

I looked through some of GoDaddy’s Managed WordPress information and one of the listed features is server-level caching, maybe that is having some effect on the WP-Cron schedule. I found some info on clearing that cache but I am curious if there is a way to temporarily deactivate it, just to rule that out as a potential cause. Are there any tools available in the server management interface that allow you to disable caching?

Hi David,

I was really hoping that solution would work, but we’ll just have to keep looking for the problem.

Log into your WordPress admin, open up your browser’s Developer Tools, and then reload the page.

Switch to the Console panel to see if there are any error messages recorded, there might something in there that gives us an idea of what it happening.

After checking the Console for errors, change over to the Network tab and check if there are any errors loading individual files (the text for those items will be red).

I also found a post in the WordPress forums that looks similar to the problem you are seeing. Apparently when WordFence is configured to hide the WordPress version in 6.0.2 it creates that broken appearance. I am not sure if your website is even using WordFence, but if so then this could be another solution.

Hopefully we can get some useful data from the Console and Network information.

Hi Mike!

There should a be link in the video description to a GitHub Gist that contains the exact code, but here is the link to view that data just in case there are any problems displaying the video description on your end.

https://gist.github.com/bwmarkle/c3ad9d5e7e2667f5c66c4ac564c7b050

Thanks again for all your help troubleshooting this!

Thank you for sending that information David!

We were unable to find anything specifically related to the missing admin styles after looking through that log data, but we did find some areas of opportunity where we can improve the logging. For instance, according to the logs it only took 2 seconds to unzip your ~770 MB backup file which doesn’t seem right.

Other than the styles in the WordPress admin, is the website working as expected? I checked the browser console and noticed that there are some mixed-content errors which could be related to the missing admin styles. There are some CSS files from the et-cache directory that are using HTTP instead of HTTPS which is preventing them from loading. I am curious if this same behavior is happening to your WordPress admin styles.

From what I can gather, et-cache is a caching solution directly managed by the Divi theme and if that cache is somehow serving your WordPress admin styles with HTTP then that would explain why deactivating the plugins did not resolve the problem. Renaming the et-cache folder in the /wp-content directory might get the styles loading again.

If that doesn’t work then I found another solution that might. You can define some Constants in your wp-config.php file that will allow files served over HTTP to load in the WordPress admin.

Did you already try refreshing your website’s permalinks as well? If defining those Constants allows the admin styles to load then refreshing the Permalinks should help ensure that most of your website assets are loaded via HTTPS.

Hi Mike!

I spoke to Brad, the lead developer for Total Upkeep, about this and right now we’re both stumped. It looks like we will need to get some additional information to figure out what is responsible for removing that Cron job.

Brad came up with a solution to log the removal of that Cron job and made a short video demonstrating how you can add the logging to your website.

You will need to install the Code Snippets plugin to apply the code to your website and the exact code is provided in the video description.

Hopefully the custom logging points us towards the culprit and please send us those results whenever you have a chance!

Hi David,

It is possible that when Total Upkeep encountered that unwritable file it caused the restoration process to error out, but it is difficult to know for certain right now.

Could you locate and send us the contents of the restoration log file that was generated when you began the restoration attempt?

Brad, the lead developer for Total Upkeep, created a video that demonstrates where you can find the restoration logs that should be a useful reference.

The information in that file should give us an idea of what went wrong with this restoration.

Hi David, sorry to hear about the problems with your dashboard following the restoration and we will do everything we can to help.

Do you know if your website is using any kind of caching plugin? My first suspicion is that there is some kind of cached data that is conflicting with the version of your website that was restored from the backup.

If you are using a caching plugin then the first thing I would try is deactivating your caching plugin to see if that clears everything up. You can deactivate plugins outside of the WordPress admin using WP CLI over SSH or by renaming the caching plugin directory with FTP or your web server’s File Manager tool.

You might also be able to get the WordPress admin styles loading again by refreshing your website’s Permalinks.

Hopefully one of those solutions gets things working correctly again and please let us know if the problem continues after trying those solutions.

Hi Mike!

Where exactly are you seeing the boldgrid_backup_wp_cron_run_jobs and boldgrid_backup_wp_cron_backup appear and then disappear from? Is there anything displayed in the WP Cron jobs field under the Cron section of the Preflight Check tool in Total Upkeep?

If the cron jobs are disappearing because of a plugin malfunction then you might be able to correct the error by deleting and then reinstalling Total Upkeep to help ensure that all of the plugins files are properly in place.

Are you running any caching plugins on your website? I have seen a few cases in the past where WP-Cron events did not trigger on websites that had Object Caching enabled in a caching plugin, maybe that is what’s happening here?

You can also test for plugin conflicts by temporarily deactivating every other plugin on your website to see if that allows the cron jobs from Total Upkeep to stick. If those jobs persist with everything else deactivated then you can reactivate the other plugins one by one to see where the potential conflict is coming from.

Another thing that you can do is installed WP Crontrol to get some additional information about all of the WP Cron events on your website and potentially find the source of the problem that way.