Support

This doesn't make much sense. Admin Tools does not block WP-CRON jobs. We know full well that WordPress itself needs these CRON jobs to function properly. It would make no reason for us to disable them.

We actually explicitly include wp-cron.php in the default list of “Files which will always be made accessible” in the .htaccess Maker configuration to ensure that WP-CRON is never blocked. Can you please check that this is the case? If not, the default list is as follows:

wp-activate.php
wp-comments-post.php
wp-cron.php
wp-links-opml.php
wp-mail.php
wp-signup.php
wp-trackback.php
xmlrpc.php
wp-includes/js/tinymce/wp-tinymce.php
wp-content/plugins/akeebabackupwp/app/index.php
wp-content/plugins/akeebabackupwp/app/restore.php
wp-content/plugins/akeebabackupwp/app/remote.php
installation/index.php
kickstart.php
wp-content/plugins/wordpress-seo/css/main-sitemap.xsl

Beyond that, there is no other feature to block WP-CRON. I have development, testing, and production WordPress sites which use WP-CRON to back themselves up (we include this feature in Akeeba Backup Professional for WordPress) and they do work.

This doesn't make much sense. Admin Tools does not block WP-CRON jobs. We know full well that WordPress itself needs these CRON jobs to function properly. It would make no reason for us to disable them.

We actually explicitly include wp-cron.php in the default list of “Files which will always be made accessible” in the .htaccess Maker configuration to ensure that WP-CRON is never blocked. Can you please check that this is the case? If not, the default list is as follows:

wp-activate.php
wp-comments-post.php
wp-cron.php
wp-links-opml.php
wp-mail.php
wp-signup.php
wp-trackback.php
xmlrpc.php
wp-includes/js/tinymce/wp-tinymce.php
wp-content/plugins/akeebabackupwp/app/index.php
wp-content/plugins/akeebabackupwp/app/restore.php
wp-content/plugins/akeebabackupwp/app/remote.php
installation/index.php
kickstart.php
wp-content/plugins/wordpress-seo/css/main-sitemap.xsl

Beyond that, there is no other feature to block WP-CRON. I have development, testing, and production WordPress sites which use WP-CRON to back themselves up (we include this feature in Akeeba Backup Professional for WordPress) and they do work.

Please verify that Admin Tools, .htaccess Maker, “Files which will always be made accessible” contains all of the lines I gave you in my previous reply. If not, please add the missing lines. Please do explicitly state whether you have checked that, and whether you made any changes. I need to know this information to further help you.

Let me explain this a bit better. The most likely cause of the problem is that wp-cron.php was missing from “Files which will always be made accessible”. Adding it and regenerating the .htaccess would solve that problem. It's easy to check, and will save us hours of troubleshooting.

If that's not the case, I will need to see the request being sent, including its URL parameters. That would allow me to check whether the root cause is a different kind of protection.

This still does not tell me what is the exact request that's being blocked.

I can try a guess. Go to Admin Tools, .htaccess Maker, and set “Block access from specific user agents” to No. Click on “Save and create .htaccess”.

If you can actually find the server access log line with the blocked request to wp-cron.php (you might have to ask your host to help if you're not familiar with how to do this) I can certainly help much better than right now.

To be fairly honest, I am currently stabbing in the dark, trying to imagine what would be the difference between your configuration and mine, as I am using the exact same plugin as you do on my own sites. Note that it's WP Crontrol, not “WP Control”; the plugin name is an awkward portmanteau of “CRON” and “control”. On my sites I have “Block access from specific user agents” disabled. This might be relevant if you or your host have set up CRON jobs which use WGet to trigger the /wp-cron.php URL on your site every minute to let WordPress process CRON jobs even when there is no inbound traffic. The default list of “User agents to block, one per line” does indeed contain Wget which would block that request. That's why I am asking you to disable “Block access from specific user agents”. If that solves the issue, then that was the problem.