Not long ago, all the periodic automatic payments of the web maintenance service suddenly stopped working, with the consequent disruption for both me and the clients, because it was necessary to carry out manual processes that you never like and make you waste time, especially when it was something you gave for fact.
After many days of research it turns out that the whole problem came from the most surprising culprit: CloudFlare. But I’ll tell you the whole process …
Index of contents
Recurring subscription payments that don’t run
Suddenly, one day, instead of generating the new orders for periodic payments of maintenance services, which I manage with the Yith subscription plugin , the orders were not generated, and consequently the payments were not loaded and they were not updated subscriptions to the service.
After checking all the common possible culprits: plugins, the theme, WordPress, or an update of the previous ones and verifying that that was not the problem, there were two fundamental tools that helped diagnose the problem .
WordPress scheduled actions
The first thing I did was go through the scheduled actions , where all the WordPress processes and their plugins that run on a recurring basis are shown, through WordPress cron or alternatives.
And the first thing I saw is that there were some of these scheduled actions that had not been executed, they were with the past date . In my case the most serious was the yswbw_schedule_subscription_payment hook, precisely the one that launches the payment of subscription services .
Of course, if I manually executed the hook from the scheduled actions, they were launched, but that is not what one expects from an automated service, is it?
Now, who was to blame for not automatically executing these programmed actions? Well, the usual first suspect is always the WordPress cron .
So I started to listen to myself and check if the WordPress cron was working or any alternative that had active. In this case I had it disabled, but I had created a real cron , so in principle it should work, but the reality is that it did not work.
Anyway I changed them and left the WordPress cron active, checking that the scheduled actions still did not work , neither those of my subscription plugin nor any other.
“Catching” the Cron
Having seen this, I went to the second tool, WP Crontrol , a wonderful plugin that you should always have in your favorites.
Once installed and activated I could verify that, indeed, there were lots of actions that were not executed .
This confirmed the problem, but did not offer a solution .
But, look where, one of the times when I checked the screen of the cron events of the WP Crontrol plugin, it received me with an error message that, this time, gave me a clue .
When it’s nice to see a 503 error
It turns out that there were cron events that generated a 503 error, or service unavailable response.
Now, this type of error can be generated by a lot of possible causes:
- Scripts
- Plugins
- Topics
- Security rules
- Server failures
But since I had already tested scripts, plugins and themes, I went on to test if some web security rule might be blocking scheduled cron actions .
In principle it was nothing that I had put on my own, neither the security plugin nor additional rules, so I only had one element of the entire system that I had not reviewed: CloudFlare, which also has security tools, another reason why I usually recommend this CDN .
The Mysterious Bot Fight Mode by CloudFlare
Reviewing the CloudFlare Firewall page all of a sudden a bunch of actions blocked by the firewall appeared , where the path was coincidentally wp-cron.php .
Going into more detail it could be seen that, indeed, there was something called Bot Fight Mode that had blocked JS processes coming from wp-cron.php .
But what was this Bot Fight Mode thing about?
Bot Fight Mode is a feature that CloudFlare included in March 2021, with 2 modes:
- Free, for all types of accounts, also free.
- Super Bot Fight for paid accounts, easier to manage and review.
But I just didn’t remember activating it, unless CloudFlare decided at the time to activate it automatically for all accounts. In any case I went through the configuration page of the CloudFlare bots, and there he was, all cute, activated.
Solution (s) to Bot Fight Mode that blocks scheduled actions from WordPress cron
So I had 2 possible solutions to my problem ahead of me:
- Completely disable Bot Fight Mode – Easy, just click on the selector and problem fixed.
- Create a rule to exclude sensitive processes from Bot Fight Mode – Somewhat more complicated, but nothing fancy either.
Initially I disabled the Bot Fight Mode, to check if the programmed actions were already running.
And, indeed, everything was working correctly.
Anyway I preferred to use the second method, leaving the Bot Fight mode active, which really serves to block many attempts by bots to access your website, but creating a rule so that it does not block my website’s cron .
In addition, it is very easy to do it, you just have to go to the Firewall Rules section and create a new rule with several simple fields, as in the following screenshot:
From now on, having the Bot Fight mode active, it will allow wp-cron.php connections from the websites indicated in the rule.
Did you like this article? You can’t imagine what you’re missing on YouTube !
