I am attempting to filter the viewing of node/cck fields attached to the nodes, so I have written a custom hook_nodeapi function and I am editing the field values if the user doesn't have permissions (redacting them). The problem is, that when cron runs and apachesolr attempts to index the same content, cron doesn't have "the permissions" associated and so ends up indexing redacted content.

I need a simple test that returns a boolean if a function is being called by cron. Any ideas? I have started looking through cron code (Drupal 6) and it looks like bootstrap sets up cron with default anonymous user account details...

  • so, the fields are available for some users but not others? is there a specific role used for these permissions? Do you want the function to behave as if it was a non-privileged user during cron? Aug 4, 2011 at 16:56
  • Basically, I need to redact content for all users except subscribed users - but the search still needs to work as though it isn't redacted - and then when people click through the search, it is redacted again. Aug 5, 2011 at 7:45

4 Answers 4


How is cron being executed? If done via crontab like

0 1 * * *   /usr/bin/wget -O - -q -t 1 http://my.site.com/cron.php

then I suspect that

function hook_whatever () {
  global $user;

  if (strpos(request_uri(), "/cron.php") === 0 && $user->uid == 0) {
    // from crontab
  } else {
    // from somewhere else

would work.

Manually running from one of the admin pages may be trickier, but taking out the $user->uid check may suffice in that case.

  • Thanks MPD, this sounds like a possibility. I am running cron from the admin interface at the moment but will probably be doing something like this later, so its a consideration. Will try your solution and get back to you. Aug 5, 2011 at 7:56
  • Thanks MPD. I am using this technique with hook_nodeapi to redact my content, and a little extra functionality in the templating of the apachesolr search results. Aug 5, 2011 at 14:58
  • Note that this fails when running "drush cron" or when invoking "drupal_cron_run()" manually. Aug 14, 2013 at 14:16

It occurs to me that the issue may not be so much cron but the apachsolr indexing itself.

Having a look in the code here it seems that you may have a couple of options.

Exclude your module from apachesolr indexing. I'm not sure where the UI is for this, but it looks like you can specifically not get called when content is being indexed.

Or you can put some custom code in your nodeapi hook which checks for op 'update index'.

Or you can check for $node->build_mode == NODE_BUILD_SEARCH_INDEX in your nodeapi op = view hook.

The only time you will have an issue is if you are putting things into nodeapi op = load, but for the purposes you describe op = view may be a better match.


You can determine whether your function is run via cron by checking if drupal_cron_run is in your debug_backtrace.

That's an awful solution, so don't do it if some other solution comes up.

  • Programmatically, I think I understand what this is doing, but I would rather look at this as a last result (as it would result in running through the entire stack? And I need this check done each and every time a node is "viewed"). Aug 5, 2011 at 7:46
  • Almost down voted but as you admit is an awful solution I didn't. Aug 5, 2011 at 9:11

In Drupal 7, the code below is how cron checks to see if a valid cron key is being used. I don't think this would render a false access grant if cron were being run concurrent to the request because the $_GET variable is a superglobal only accessible to that script. Correct me if I'm wrong.

if (isset($_GET['cron_key']) && variable_get('cron_key', 'drupal') == $_GET['cron_key']) {
  //do my fancy cron stuff here

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.