Keep running cron when bad PHP content is encountered

I already described the only possible way to handle that (and the related redirect issue):

http://drupal.org/node/286263#comment-979102

there are a bunch of dupes of this issue. i'm of the opinion that it's a node.module issue and not a search.module issue -- could be handled with an error trap in node_update_index() in node.module, see 744276 for more in-depth description.

also of the opinion that the resultant "Cron run exceeded the time limit and was aborted" error message is a bug worthy of fixing before 8.x.

#361171: How to debug cron stoppage problems with bad PHP content
#744276: Crashy PHP node causes search index to fail, misreports condition as "Cron run exceeded the time limit and was aborted"
#286263: Make search indexing smart to handle nodes wth php redirects
#308808: Drupal_cron_cleanup paints the wrong picture
#752184: Keep running cron when bad PHP content is encountered
#643474: Invalid PHP code in node, causes whole cron task to crash

The difference between 286263 and all these other ones (where the phrase "bad code" keeps getting used over and over) is that using drupal_goto() is NOT "bad code". So you are correct here when you say that there are two issues. 286263 is a BUG because part of Drupal doesn't understand how to work with the Drupal API. The others are support or feature requests because sometimes people write bad code.

Interesting response. So at risk of going OT, do you consider using any and all Drupal API commands within PHP content to be a hack? And is this the general consensus, a documented best practice, or a personal opinion?

Interesting indeed (subscribe).

Running any function with side-effect inside the node body is indeed bad code.

Fair enough, I do see your point from a security perspective. But when I see the phrase "bad code" I think of things like unbalanced brackets or unclosed quotes, arrays confused with objects, syntax errors, one-off errors, eternal loops, etc.

In other words, if ALL PHP code inside a node is "bad code" then it's really a rather moot point to differentiate bad from good, no?

Sounds fair enough to me too. My interest was that under certain dynamic conditions, I issue a drupal_goto() in the hook_nodeapi view operation. hook_menu won't work for this. The drupal_goto() is wrapped in a cron semaphore check so cron operations won't abort.

How do you do a cron semaphore check to manually wrap code that calls drupal_goto in drupal 6?

Basically:

if (!variable_get('cron_semaphore', '')) {
  drupal_goto(...);
}

But note this also means that regular users will not get the drupal_goto() while cron is running.

hi

I would actually like to add this issue #302739: Watchdog interferes with cron semaphore deletion in drupal_cron_cleanup() as a part of this and say that this might not only be considered as a problem with the search module. And also that this isn't a feature request but a bug.

I've seen the comments indicating this is not considered a problem with the search module. I'm not so sure about that, since PHP code is probably doing something dynamically, showing different content to different users. The search index is therefore likely to contain something that the current user will not see when they visit the node with PHP code.

More immediately, I am looking for some way to determine, in my PHP code, whether the search index is currently being built. That is, I'd like put something like this in a text field with PHP code filter...

if (search_index_is_currently_being_built()) {
  // Do nothing.
} else {
  // Do something.
}

My problem is I can't figure any way to test for that. The fact that index is being rebuild seems to be known as the view mode of the node. But the filter, or code being evaluated has no way to learn that, as far as I can tell. I'm trying to do this in D7, by the way.

Any help is appreciated. Thanks.

UPDATE... I'm using the following, for the time being. Using the fact that cron module sets a lock, and search index is rebuilt via cron (even when cron is running in page footer, which is how I first noticed my problem). But I'd like a cleaner test, so feel free to suggest improvements. Thanks.

  // Avoid any calls to drupal_goto when Drupal search index being built, which is done via cron.
  if (!lock_may_be_available('cron')) {
    return;
  }

  // The code I'd like to run when the node is viewed goes here.

The php filter module has been removed from Drupal 8 for exactly this sort of reason - it's too powerful and can't be locked down.

I'll set this back to D7 in case anyone wants to work on a 'fix', but my recommendation to anyone encountering this problem is to disable the php filter module and find alternative ways to do what you're trying to do (e.g. write a custom module).