Hi,
As long as your server is configured correctly and you are getting a steady stream of visits from users and web crawlers etc everything should run very well.
WordPress scheduler automatically runs every time something visits the blog, but no more than once a minute. When it detects jobs need running it will attempt to “visit itself”, then deal with the actual visit, so the “visit itself” does the work, while the current visit can be dealt with immediately and without delay. WP_ALTERNATE_CRON in wp-config will do it slightly differently and works for some people. When it detects jobs need running it will redirect the visitor so they can be dealt with immediately, and then deal with the work. So, both ways make sure the visitor gets a quick page load, and that jobs still get run.
These are the two different approaches by WordPress. The first one the default and working the best for most people.
However, the problem comes if your blog is https://www.blog.com, but the server hosting it doesn’t know where that is (an example of poor configuration by a web host… sometimes it is referred to as “server doesn’t allow loopbacks”.) WordPress tries to “visit itself” on default configuration and finds that when it tries to access https://www.blog.com… it gets back a failure. Thus the scheduled jobs do not run. It is this instance where WP_ALTERNATE_CRON is provided as a workaround.
Another issue you might have is the schedules run but they run far too late (since they require a visitor and maybe you aren’t getting many visitors). WordPress consider this acceptable since if there are no visitors, visitors don’t notice a problem!
One way to fix this is to use Cron Job on your server, but this still requires that your server can find your blog, https://www.blog.com for example. You’d enable DISABLE_WP_CRON in wp-config so it knows not to do schedules when visitors visit, and you’d create a cron job to run every 5 minutes or so and make the command something like “wget -q -O – https://www.blog.com/wp-cron.php?doing_wp_cron &>/dev/null”.
The plugin you mention only fixes missed scheduled posts and I believe is only needed in the situations where WP_ALTERNATE_CRON would be intended to be used. The plugin likely publishes the posts when a visitor visits but does it before the visitor is dealt with. So it will delay the visitor’s page load slightly, but since publishing a scheduled post is simple it likely is insignificant. However, doing the backup is not simple and much heavier work so it would not be feasible at all to have a similiar plugin.
Usually, things just work. If not, WP_ALTERNATE_CRON is the best second approach.
If schedules run sporadically and too late, the site is low visitors, so don’t use WP_ALTERNATE_CRON and setup Cron Job instead. But once web crawlers start indexing this normally fixes itself.
I hope you don’t think TLDR ?? But I figure it would be good to document all this here for all to see if anyone else has similar issues again. Google searching WP_ALTERNATE_CRON etc will bring up some good guides.
Regards,
Jason
