Hi there, Any update on this? Any update is a good update.

Hi There, I was wondering if there's anything on this? One of the reasons I moved to this plugin was the lovely way it handled 2FA. Any updates are good updates :)

Hi, I've been doing some more testing on this and narrowing the issue down. The problem appears to be between WP-Defender and Awesome Support. If I have WP Defender-Pro installed, with Manage Login Duration set to 7 days, my Backup Buddy backups fail. The testing shows that the wp-cron.php Loopbacks are failing. If I disable Manage Login Duration, the backups and my other Cron jobs run just fine. To test this, I disable ALL plugins except Awesome Support, WP-Defender Pro, WPMUDev Dashboard and Backup Buddy and can replicate the problem. I have a test site setup where this can all be tested without affecting the live site, if you would like the details sent through.

No problems. I have a scratch site that has very few plugins on it. I'll replicate the settings over there and advice as well. Thanks so much for the update.

No worries. I do want to point out that it was working before I did the update to WordPress 5.0 - because I had to log in to do it :). It was only when I went to log back in after I did the update that it started failing and what prompted me to set up a scratch site to test with. Hopefully it will be fixed soon because it's such a good security precaution.

Hi there, I don't mind. That's a scratch site and you can play with it. Those details have been sent. I do want to point out that this was all working fine before the WordPress 5.0 update. Now, that could be anectdotal but I don't believe I've changed anything on the server that would change the time, unless there's been a security update go through.

Hi Kasia, Apologies for the delay . That information has been sent.

Hi. Access is granted. Please note that I have reverted the changes so that my cron jobs run. To test: 1. I noticed my backup buddy backups weren't running and I also noticed that a cron job I have setup to modify my_cred balances wasn't triggering (not related to Backup Buddy at all). 2. I used the Backup Buddy Server Tools to find that wp-cron.php Loopbacks was disabled. Reading the return results from that test told me that the test was being presented with the 'please re login' message. 3. I reverted the changes on Defender for Manage Login Duration and tested again. wp-cron.php Loopbacks were enabled and all the cron jobs on the site ran. I also ran a manual full backup to be certain. 4. I reenabled Manage Login Duration. wp-cron.php Loopbacks were disabled, the message was in the return code, my cron jobs didn't trigger and a manual full backup was stuck waiting for a response. 5. Reverting the changes fixed the problems again.

My apologies, I missed this request! As I said, I suspect that the visitor was using a cacheing proxy server - through their corporate facility. So you are correct in that, just not Cloudflare. And that is the issue and why you can't recreate it. What I'm suggesting is that the 404 detection be able to set to ignore Hummingbird assets in case this happens again. I certainly don't want to whitelist the folder, but using Regex or even a checkbox that says "ignore Hummingbird cacheing assets" would work. I haven't noticed the problem again but it is still a concern that it might occur.

Hi There, No it wasn't one of my accounts, it was one of the site owners testing for me. When they first visited the site, the style sheet didn't load and then after trying to refresh and navigating to a couple of other pages, they were blocked. You can see the block in the logs on the site for IP blocks in Defender. I white listed after that to get the testing done. Around that time, the site started displaying for them. The particular visitor had not visited the site before , so the load was a new one. When they had problems with the display, they cleared their browser cache and restarted their browser. They also tried a second browser (IE was first, Chrome was second) and had the same display issues. They can't confirm but I suspect there was a proxy cache involved in the chain somewhere. The issue is - if that is the case, I need to be able to whitelist assets that are created by Hummingbird so they don't throw the 404 exception that gets flagged by Defender.