I have written a custom module (for Drupal 7 and PHP 5.3) that utilizes hook_nodeapi() and doesn't allow access to a specific node type and simply redirects (with drupal_goto()) to the main listing page with a warning message.

However I have a suspicion that the Boost module (with "Don't cache pages with messages" enabled) chokes on cron runs when it gets to these content types and keeps getting redirected (I don't know how Boost exactly works but I guess it caches few pages on cron runs?).

The reason for my suspicion, and the real problem is that the cron, after a certain number of runs, starts failing with an error message, "Cron run exceeded the time limit and was aborted.", and immediately after this message on Watchdog there's the following message, "There are Drupal messages on this page, preventing boost from caching."

I put a debugging piece of code on module.inc (hacked core as was suggested here) to see which module was responsible for this failure, and everytime the cron fails, the last module that accessed the Cron seems to be the "Search" (core) module:

boost 22/02/2012 - 9:00am There are Drupal messages on this ... Anonymous
cron 22/02/2012 - 9:00am Cron run exceeded the time limit and was aborted. Anonymous
cron 22/02/2012 - 9:00am hit search cron Anonymous
cron 22/02/2012 - 9:00am hit node cron Anonymous
cron 22/02/2012 - 9:00am hit filter cron Anonymous
cron 22/02/2012 - 9:00am hit dblog cron Anonymous
boost 22/02/2012 - 9:00am Expired stale files from static page cache. Anonymous
cron 22/02/2012 - 9:00am hit boost cron Anonymous

I have since then reduced the number of pages to index but it didn't help. The cron that runs after the Search cron is the "System" cron but I have no idea what exactly this cron does.

The annoying thing is when you access the cron page through typing in the browser http://address/cron.php or through commandline wget http://address/cron.php it runs Ok. But from the system's cron jobs it eventually runs into this problem after few successful cron runs.

I would appreciate any help in getting to the bottom of this problem or a push in the right direction. Thanks.

 * Implements hook_nodeapi().
function rhask_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
  switch ($op) {
    case 'view':
      if($node->type == 'question' && arg(0) == 'node' && !user_access('administer questions')){
        drupal_set_message('Access Denied - You cannot access this content directly. Please use this page.', 'warning');

I guess I could do a redirection without setting any message. That might solve it if indeed Boost is causing problems with the cron, I'll edit this post when I get any result by doing so.

Edit: The cron has been running successfully every 30 minutes since yesterday and the change I've made to the XMLSitemap module's settings seems to have done the job. I will continue to monitor this website for few more days.

Edit2: Cron still fails. I've removed the drupal_set_message so now it redirects without setting any messages. However it doesn't prevent the cron from failing. Boost doesn't complain anymore and just logs that "Expired stale files from static page cache". I don't know how to proceed from here to isolate this problem.


2 Answers 2


I suspect you could check that arg(0) == "node" and is_numeric(arg(1)), which would detect the internal path for a node display and not cron. You would also need to check arg(2) for "edit" and a few others, that may (or may not) appear as local tasks for your nodes.

  • Yeah that's what I have done. But I forgot to mention that there's also a permission check in order to block Anonymous users but allow users with this permission to access the node. I guess since the cron runs as an "Anonymous" user, it doesn't have the permission so it gets redirected to that page. I've updated the original post with my hook_nodeapi.
    – Beebee
    Commented Feb 22, 2012 at 13:48
  • I've solved this by checking for variable $a4, as it's not NULL only when it comes from node_view()
    – Beebee
    Commented Apr 3, 2012 at 8:08

We've solved this. drupal_goto invokes hook_exit which was causing the cron runs to fail. We've stopped this by checking for variable $a4 of hook_nodeapi if it's not NULL (means it's being called from node_view() and not from cron) then proceed with drupal_goto

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.