I recently worked with a WordPress MU installation. As an ease of deployment and probably because it is largely used on shared hosting which may not offer access to cron jobs, WordPress default way of processing its scheduled tasks is through front-end and admin page requests. As a result, everytime a page is requested, the system looks to see if there are jobs to run. When so a call is performed to execute the tasks. The asynchronous nature of the call makes it somewhat transparent from the webuser perspective.
Although it works well, I do not feel confident to use this mechanism on a site with a lot of traffic. After some google searches to find out how it works, I’ve read many stories about hosting companies denying access to wp-cron.php because of bad impact on their server.
I had another issue while using WP-SuperCache. Since the super cache is super because it prevents loading the whole PHP engine for guest requests. Unfortunately, no php code execution means no cron execution for super cached pages… Since the cron is responsible of cleaning the super cached files, they are served indefinetly or until a user logs in (logged users do not get super cached files).
So for all the good reason I had, I wanted to run WordPress cron jobs from a real cron schedule.
Pages: 1 233 comments