How to Replace WP-Cron with Linux Cron pt. 2

by Rian

It’s been about 4 months since I wrote about wp-cron madness. To reiterate why wp-cron had to be called manually, that’s due to how some of the cron jobs weren’t executed even though it was queued for prolonged time. I’ve tried three different methods, one of which was to tackle only the cache. As of writing this, I’m settled with wget method.

One of the problems I faced immediately with php method was that its behavior is wildly unpredictable. When wp-cron was executed manually via php, some of the cron jobs were still queued. And these jobs were often cache related jobs, meaning, finding the culprit isn’t going to be easy. Manually running the command didn’t flush the queue either. It had to be HTTP, or else. Some discussions I’ve read had disintegrated into blaming shared hosting, instead of giving me some pointers. Shared hosting has its own shares of problems, one of which is ever-changing server environment, but without knowing why, without knowing what is the root cause of it all, I wouldn’t say php was a reliable solution.

The main counter argument against using curl or wget is its network overhead. Mind you, it would be equivalent to a single bot visit. It won’t drastically affect the performance of your website; not to mention, if your website is unreachable via internet, you have another problem on your hand. I would argue we are inflating the problem that is the network overhead. There is a reason why most hosting service providers have a support document on replacing wp-cron with wget or curl.

All in all, from my 4 months of testing, I recommend using wget. I’ve used wget for preferences reason, but the issue at hand is simple. Using php to trigger wp-cron from server side does not execute all cron jobs. With all seriousness, if I were to hazard a guess, wp-cron may be written with manually running from server side in mind, but most third party softwares benignly assumed default wp-cron behavior in mind. After all, wp-cron, at core, is designed to be triggered upon visitation; in theory, either of the HTTP methods would be more similar to what third party developers would expect out of WordPress environment.

1. In the text editor, add the following line in the wp-config.php file, which will be inside the site’s public_html folder:

define('DISABLE_WP_CRON', true);

2. From cPanel, add the following the command with cron schedule expression:

[schedule expression] wget --quiet --output-document=- '[url of website]/wp-cron.php?doing_wp_cron' >/dev/null 2>&1

On mine, the actual command looks like this:

*/5 * * * * wget --quiet --output-document=- '[url of website]/wp-cron.php?doing_wp_cron' >/dev/null 2>&1

It’s nearly identical to how it was before, except I’m using some syntaxes to make sure I’m throwing out all the results. Again, don’t forget to make changes to wp-config.php file. It won’t break the site, but it would be unnecessary for wp-cron to run on every visit.

As for the efforts to make php to run reliably with all the other plugins and solutions, I had to accept that it’s a compromise. Most WordPress projects are either open source and/or have community support system, so it’s not a dead end. There is a merit in discussing the potential cause. But I would argue discussing the subject outside of a developer forum would go against the idea of using WordPress, that is the convenience of self-hosting, that is the universal (or near universal) solution of blogging for people, especially when we have an alternative fix that is known to work.