我看过很多关于这个问题的帖子，但很少有人能找到真正的解决方案。对我来说，解决这个问题的方法是在中管理重定向。htaccess文件。

下面是一个如何通过在中添加这些行重定向url的示例。htaccess文件：

<IfModule mod_rewrite.c>
    Options +FollowSymLinks
    RewriteEngine On
    RewriteCond %{QUERY_STRING} (^|&)doing_wp_cron= [NC]
    RewriteRule (.*) /$1? [R=301,L]
</IfModule>

注意：此提示来自this forum

@scribu我相信BackupBuddy使用WordPress任务调度来调度任务，作为备份过程的一部分-如果站点禁用了环回，那么只有解决方案（除了一些定制的外部解决方案）和特定的替代解决方案（我相信您知道，它集成到WordPress中）才是替代cron修复。因此，只有当主机禁用了环回时，这才是“必需的”。请记住，如果是这种情况，则无计划任务，无论是标准WordPress计划任务还是与其他插件相关的任务，都可以工作。情况似乎是这样的，用户在尝试BackupBuddy之前不会知道他们的主机已经阻碍了WordPress的安装，因为这会使问题变得明显，而不是直到那时才被发现。

使用crontab类型的方法只是一个难题，因为除非您经常“ping”WordPress cron处理，否则它只能处理某些类型的计划任务。

当然，如果用户不想或不能使用备用wp cron修复程序，不想移动到允许环回的主机，并且不具备足够的知识，无法设置合适的基于crontab的功能，那么BackupBuddy确实提供了一种手动备份模式，该模式可以正常工作，但它缺乏灵活性，无法在调度可用时提供一些可用的功能。

导致此问题的是备用cron。要解决此问题，如果您有访问权限，可以启用actual cron process （如果您的主机允许）并在WP配置中禁用ALTERNATE\\u WP\\u CRON。php。